[FEATURE] Avoid exec as liveness probe

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
According to this https://github.com/opencontainers/runc/issues/2532
liveness probe with exec for every seconds seem consume too much resource.
Can we avoid liveness probe with exec in instance managers?
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Actually we had encountered this issue then modified the period to 5s from 1s: https://github.com/longhorn/longhorn/issues/767
Maybe we still need further investigation for this liveness probe.

@shuo-wu I suspect it leads the system into #2297

Actually we had encountered this issue then modified the period to 5s from 1s: #767
Maybe we still need further investigation for this liveness probe.

grpc-health-probe default timeout is 1s, and longhorn probe every seconds. In case server is not reachable, longhorn actually make the second probe before the first one completed. I don't if this will mess up k3s and runc runtime in some way.

Actually we had encountered this issue then modified the period to 5s from 1s: #767
Maybe we still need further investigation for this liveness probe.

grpc-health-probe default timeout is 1s, and longhorn probe every seconds. In case server is not reachable, longhorn actually make the second probe before the first one completed. I don't if this will mess up k3s and runc runtime in some way.

For the gRPC health probe, there are 2 timeouts:
Usage of grpc_health_probe:
  -addr string
    	(required) tcp host:port to connect
  -connect-timeout duration
    	timeout for establishing connection (default 1s)
  -rpc-timeout duration
    	timeout for health check rpc (default 1s)

Based on this info, we can set the Longhorn liveness probe TimeoutSeconds to 2s, then there won't be more than 1 probe running. But I don't think it is the root cause since thee liveness probe could start 2 probes at max with the current setting.

Based on this info, we can set the Longhorn liveness probe TimeoutSeconds to 2s, then there won't be more than 1 probe running. But I don't think it is the root cause since thee liveness probe could start 2 probes at max with the current setting.

Providing runc as it should, I agree with you, but if runc takes a bit long time to clean up exec, would it be the case?

@ElisaMeng It seems like the feature is related to https://github.com/longhorn/longhorn/issues/2297?
Currently, We have probe configurations as below
initialdelayseconds: 3
timeoutseconds: 1
periodseconds: 5
successthreshold: 1
failurethreshold: 3

The configuration covered the slow starting container  set up a startup probe with the same command with a failureThreshold * periodSeconds long enough to cover the worse case startup time as described in Configure Liveness, Readiness and Startup Probes.  However, the same document has notes and caution as below:
Note:
Before Kubernetes 1.20, the field timeoutSeconds was not respected for exec probes: probes continued running indefinitely, even past their configured deadline, until a result was returned.

This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior, even without realizing it, as the default timeout is 1 second. As a cluster administrator, you can disable the feature gate ExecProbeTimeout (set it to false) on each kubelet to restore the behavior from older versions, then remove that override once all the exec probes in the cluster have a timeoutSeconds value set.
If you have pods that are impacted from the default 1 second timeout, you should update their probe timeout so that you're ready for the eventual removal of that feature gate.

With the fix of the defect, for exec probes, on Kubernetes 1.20+ with the dockershim container runtime, the process inside the container may keep running even after probe returned failure because of the timeout.

Caution: Incorrect implementation of readiness probes may result in an ever growing number of processes in the container, and resource starvation if this is left unchecked.

We will continue to monitor the behavior of liveness probe as we update Kubernetes runtime to v1.20+.  However, maybe we can close the issue for now since the root cause is caused by the mal-formulate script?

@ElisaMeng It seems like the feature is related to #2297?
Currently, We have probe configurations as below
initialdelayseconds: 3
timeoutseconds: 1
periodseconds: 5
successthreshold: 1
failurethreshold: 3

The configuration covered the slow starting container  set up a startup probe with the same command with a failureThreshold * periodSeconds long enough to cover the worse case startup time as described in Configure Liveness, Readiness and Startup Probes. However, the same document has notes and caution as below:
Note:
Before Kubernetes 1.20, the field timeoutSeconds was not respected for exec probes: probes continued running indefinitely, even past their configured deadline, until a result was returned.

This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior, even without realizing it, as the default timeout is 1 second. As a cluster administrator, you can disable the feature gate ExecProbeTimeout (set it to false) on each kubelet to restore the behavior from older versions, then remove that override once all the exec probes in the cluster have a timeoutSeconds value set.
If you have pods that are impacted from the default 1 second timeout, you should update their probe timeout so that you're ready for the eventual removal of that feature gate.

With the fix of the defect, for exec probes, on Kubernetes 1.20+ with the dockershim container runtime, the process inside the container may keep running even after probe returned failure because of the timeout.

Caution: Incorrect implementation of readiness probes may result in an ever growing number of processes in the container, and resource starvation if this is left unchecked.

We will continue to monitor the behavior of liveness probe as we update Kubernetes runtime to v1.20+. However, maybe we can close the issue for now since the root cause is caused by the mal-formulate script?

This issue is tackled by #2699. So we consider it as fixed. Close it.


Doc Feedback: Please add diagrams to explain usecase

Location : https://ei.docs.wso2.com/en/7.2.0/micro-integrator/use-cases/tutorials/file-processing/
Please add diagrams to explain usecase, people don't have all day to read text.
To improve UX and convey idea/message quickly, diagrams are must

https://mi.docs.wso2.com/en/latest/learn/integration-tutorials/file-processing/


Don't populate components from node metadata if Features are provided

Description
If Features are present, they should include all the necessary components, and using the metadata to populate components is redundant and unnecessary. It is only relevant if performing non-host-level node scanning.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added

N/A

[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

Testing Performed

UTs.
Manual testing.

/test gke-qa-e2e-tests

/test gke-nongroovy-e2e-tests


Invalid UTF-8 was detected in one or more arguments

Running a WASM file with a binary argument, such as:
wasmtime run hmac_md5 --key `printf "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"` "String to hash"

or
wasmtime run hmac_md5 -- --key `printf "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"` "String to hash"

Aborts execution with the following error:
error: Invalid UTF-8 was detected in one or more arguments

I see three problems with this:

There is no standard I'm aware of that requires the arguments to be textual
There is no standard that requires them to be UTF-8 encoded
Wasmtime is doing unneeded work while validating the arguments, and/or converting them to UTF-8

Arguments are text, not binary data. For example on Windows it has to transcode from UTF-16 (as provided by the OS) to UTF-8 (as expected by wasi programs) Additionally null bytes are not allowed in arguments on Windows and Unix as they indicate the end of the argument (on Unix) or the end of the entire commandline (on Windows).

I believe we have to differentiate between two types of arguments here: arguments to wasmtime itself and arguments to the executed program. The program in its minimal variant will look like this:
int
main(int argc, char *argv[]) {
    // parse 2nd type of arguments here and convert them to whatever encoding necessary,
    // or fail if encoding doesn't fit the design
}

Right now wasmtime is forcing UTF-8 arguments on the program itself, which is IMHO quite limiting for the program (if done by design).

If you want the program to run on Windows, UTF-16 to UTF-8 conversion has to be done one way or another as wasi programs don't know the host architecture.

Also, command-line arguments are already not suitable for passing arbitrary binary data, because they're passed to C programs as NUL-terminated strings, so they can't contain embedded 0 bytes. If you want to pass arbitrary binary data as arguments to programs today, I suggest using an escape or quoting system, or a format like BASE64, to ensure that all the bytes are preserved.

I believe there's a bug here where the wasmtime executable shouldn't panic on invalid-utf-8, but otherwise I agree with others that your program shouldn't rely on being able to receive arbitrary bytes as arguments.
Additionally the wasmtime CLI has no way of actually communicating this argument to the program at this time. The wasmtime cli can only invoke functions which take numbers as input, which means that even if this were accepted it wouldn't end up doing anything.

I believe we're concentrating on the wrong side of the coin. Binary arguments are useful for unit tests, where you fully control the environment, know the limitations, and want as little opcodes as possible between the essence of the test and the environment.
The other side of the coin is the forceful conversion of arguments to the UTF-8 encoding, which is a rather large constraint IMHO considering the zoo of character encodings out there. Perhaps the problem with UTF-16 on Windows, which as I understand is the main reason for conversion to UTF-8, can be solved some other way?
p.s. There is a relevant discussion on the SG-16 group page: https://github.com/sg16-unicode/sg16/issues/66, it seems they aim to solve the same problem that we're facing?

Binary arguments are useful for unit tests, where you fully control the environment, know the limitations, and want as little opcodes as possible between the essence of the test and the environment.

On Windows, binary arguments would have to have a multiple-of-two size as the argument list consist of a single 16bit character list. In addition on Windows the program itself it responsible for parsing the argument list from a single string into however many arguments the user intended to parse. This is not the responsibility of the shell like on Unix. This means that if your binary argument contains a space character, it would either cause two arguments to be passed, or you would need to escape it, which doesn't really work well with binary arguments I would think.

The other side of the coin is the forceful conversion of arguments to the UTF-8 encoding, which is a rather large constraint IMHO considering the zoo of character encodings out there.

How would you suggest making wasi programs agnostic to the character encoding without forcefully converting from and to UTF-8 at the boundary between the wasi program and the runtime? On Windows the A variants of all system api's have a behavior depending on the system character set, which wasi programs can't query and even if it could, now wasi programs would need to ship with huge tables translating between every possible character set and whatever encoding it uses internally (like UTF-8).

How would you suggest making wasi programs agnostic to the character encoding without forcefully converting from and to UTF-8 at the boundary between the wasi program and the runtime?

Perhaps a flag to wasmtime, which defaults to UTF-8? Something like:
wasmtime --default-encoding=[system|utf-8|...]

This was the first thing I was looking for after facing the problem the first time. It might not be perfect, but at least intuitive. :)

I believe we're concentrating on the wrong side of the coin. Binary arguments are useful for unit tests, where you fully control the environment, know the limitations, and want as little opcodes as possible between the essence of the test and the environment.

For a truly minimal unit test, could you use the embedding API, instead of the CLI? Command-line arguments involve quite a lot of code, on both the host side and in wasm, even ignoring the character encoding issues. With the embedding API, you can have a function that takes an array of u8 directly, which would avoid the whole question about string encodings, and avoid all the command-line argument code too.

For a truly minimal unit test, could you use the embedding API, instead of the CLI? Command-line arguments involve quite a lot of code, on both the host side and in wasm, even ignoring the character encoding issues. With the embedding API, you can have a function that takes an array of u8 directly, which would avoid the whole question about string encodings, and avoid all the command-line argument code too.

I definitely agree with your reasoning. My only comment on that, is that Linux CLI is based on a mature code-base and provides a "battle-proven" solution for almost any upstream/downstream problem, while embedding API almost always lacks an "in-house" solution and requires a third partly library, that is generally either not mature enough or not maintained for years. So there are advantages and disadvantages in both approaches.

I'm a little unclear about what you're referring to. When I say embedding API, II mean Wasmtime's embedding API: https://docs.wasmtime.dev/lang.html
I can also mention that the current direction for WASI is that it will define command-line arguments to be Unicode strings. While it may be useful in some unit-test-like use cases to let users that know how the host environment works to take advantage of it, the goal in many real-world wasm use cases is to have modules that don't know the environment, and don't interact with the "system" character encoding, because such knowledge would make them less portable.
This only applies to things which are called "strings", which includes command-line arguments. If you have APIs that take u8s, you'll always be able to pass arbitrary bytes through.


Release v1.7.8

PR for release v1.7.8

/ok-to-test sha=d9d1c0c676b406c535c065660f82836f570bd0f7

/ok-to-test sha=645241e

@rohitagarwal88 same needs to be done for EE


Error mounting configuration files

Problem description
I cloned the git repo from main to a folder in my home directory. I ran docker compose build and it worked with no errors. However, when I run docker compose up setup, I receive the following error:
WARN[0000] mount of type `volume` should not define `bind` option
[+] Running 4/0
 ⠿ Network docker-elk_elk                Created  0.0s
 ⠿ Volume "docker-elk_elasticsearch"     Created   0.0s
 ⠿ Container docker-elk-elasticsearch-1  Created  0.0s
 ⠿ Container docker-elk-setup-1          Recreated    0.0s
Attaching to docker-elk-setup-1
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/Users/username/git/docker-elk/elasticsearch/config/elasticsearch.yml" to rootfs at "/usr/share/elasticsearch/config/elasticsearch.yml": mount /Users/username/git/docker-elk/elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Extra information
Attempts to solve:

I looked into fixing this issue with fixing permissions like #861
I tried cloning the repo to the /tmp folder instead of /home
I tried re-writing the docker-compose file with long-syntax volume mounts

However, I was able to achieve success in building and running the stack with a workaround. If I remove all of the volume mounts (except for the elasticsearch data volume created by docker-compose.yaml:52/113) and use COPY statements in each Dockerfile to transfer the configuration files to each container, the stack starts up with no issues. Note: required 3cpu/6gb memory on colima because 2cpu/4gb was causing issues.
Stack configuration
No changes to the repo. Running Colima (v0.5.5) on an ARM M1 Macbook (MacOs 13.4.1).
Docker setup
$ docker version

Client: Docker Engine - Community
 Version:           23.0.1
 API version:       1.41 (downgraded from 1.42)
 Go version:        go1.19.5
 Git commit:        a5ee5b1dfc
 Built:             Thu Feb  9 19:15:59 2023
 OS/Arch:           darwin/arm64
 Context:           colima

Server:
 Engine:
  Version:          20.10.18
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.6
  Git commit:       e42327a6d3c55ceda3bd5475be7aae6036d02db3
  Built:            Sun Sep 11 07:10:00 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc:
  Version:          1.1.4
  GitCommit:        5fd4c4d144137e991c4acebb2146ab1483a97925
 docker-init:
  Version:          0.19.0
  GitCommit:

$ docker-compose version

Docker Compose version 2.20.2

Container logs
$ docker-compose logs

docker-elk-kibana-1  | [2023-08-09T01:28:01.478+00:00][INFO ][node] Kibana process configured with roles: [background_tasks, ui]
docker-elk-logstash-1  | Using bundled JDK: /usr/share/logstash/jdk

This is a very interesting error. (The warning on the first line is harmless, you can ignore it.)
I have a feeling that Lima's sshfs might be the culprit here. Possibly the files on your host were not fully synced into the VM?

If you ssh into it, is /Users/username/git/docker-elk/ populated?
If yes, what does file elasticsearch/elasticsearch.yml return inside that directory?

What is the guest OS inside the Lima VM?

Thanks @antoineco for getting back to me so quickly!
The only file in /Users/username/ was Library/Caches/colima/. This does suggest that something is not being mounted correctly but, as you mentioned, I am still able to do other tasks that should also require a mounted fs. I understand if you believe that this is out of scope but I appreciate your help nonetheless.
In some more testing I found that:

If, in docker-compose.yml,  I mount ./elasticsearch/config to a random directory instead of mounting ./elasticsearch/config/elasticsearch.yml to /usr/share/elasticsearch/config/elasticsearch.yml, the error goes away
If I mount ./elasticsearch/config to /usr/share/elasticsearch/config (which i realize would break things later), the error goes away
If I touch /tmp/a.yml  in the Dockerfile and mount ./elasticsearch/config/elasticsearch.yml to /tmp/a.yml, the error persists

Here is my lima VM info:
❯ colima ssh

colima:~$ uname -a
Linux colima 5.15.68-0-virt #1-Alpine SMP Fri, 16 Sep 2022 06:29:31 +0000 aarch64 Linux

colima:~$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.16.2
PRETTY_NAME="Alpine Linux v3.16"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
BUILD_ID=""
VARIANT_ID="clm"

The only file in /Users/username/ was Library/Caches/colima/. This does suggest that something is not being mounted correctly

Ah, there you go! Mounting files inside containers requires them to be present on the Docker. Copy files into images, on the other hand, is done by copying the build context over a client-server communication, which is why this approach worked for you.
I've had a very good experience working with Lima myself, also for working with containers. I don't know what Colima is adding on top, but adding a mount for your home directory to your Lima definition should allow you to resolve this situation.

Yes, that fixes it! It seems as though I had some non-standard mounts from an old project left behind. Thank you for your help!!


Investigate integrating CKAN with AAD

We need users to be able to authenticate with CKAN during the Hackathon which would be easier to do if they can use their AAD identities.
This is a time-boxed spike: Max 3 hours.
Definition of Done:

Users can authenticate with CKAN using AAD.

Timebox for a few hours.

CKAN has been parked, no longer chasing as potential candidate


Errors are thrown after promise resolution

Describe the bug
When calling a SDK method and an error occurs, the promise is resolved with undefined result, and the error is thrown in another async loop later.
To Reproduce
dbx.filesListFolder({ path: 'WhateverWrongPathYouCanImagine' }).then(console.log).catch(console.error);

Expected Behavior
The error logged in console.
Actual Behavior

The DropboxResponse  with result: undefined logged in console
A second unhandled error message in console.

Versions

7.0.0
Typescript
Node 14

Solution
In response.js, add a return in line 15:
  if (!res.ok) {
    res.text()
      .then((data) => {
        // eslint-disable-next-line no-throw-literal
        throw {
          error: data,
          response: res,
          status: res.status,
        };
      });
  }

must be:
  if (!res.ok) {
    return res.text() // <= HERE IS THE FIX
      .then((data) => {
        // eslint-disable-next-line no-throw-literal
        throw {
          error: data,
          response: res,
          status: res.status,
        };
      });
  }

I submitted a fix: #342

Thanks for sharing the fix! This should be released with v7.1.0.


Access previous values

Would it be possible to access the previous value of the changed input?  This would allow for swapping values around.
For example:
  {
    field: 'opt1',
    updates: {
      opt2: (opt1Value, allValues, prevOpt1Value) => prevOpt1Value
    }
  }

Ehy guys do you still think this is useful?
I created a pr for that (#24), I personally have a particular use case and this is useful form me.
Basically I want to initialize a form with value but since I have some values that on change needs to clear some other I end up having a clean form instead of an initialized one.
Adding previous values I can check if the previous value is undefined and prevent the update to happen, or well return the current value instead.
Let me know

Published fix in v1.3.0.


1727 create instance nested kwargs

TODO:

[ ] Add to DTO tutorial
[ ] Add How To section in DTO usage docs
[ ] More tests

This PR adds a feature to the DTOData.create_instance() method that supports providing values for arbitrarily nested data via kwargs using a double-underscore syntax. For example data.create_instance(foo__bar="baz").
In the following example, the DTO is configured to exclude the baz attribute from request data, but the field has no default, and so is required in order to be able to instantiate the hierarchy of models. The kwarg foo__baz="world" is passed to create_instance() call, which gives Bar.foo.baz a value.
from dataclasses import dataclass
from typing import Any, Dict

from typing_extensions import Annotated

from litestar import post
from litestar.dto.factory import DTOConfig, DTOData
from litestar.dto.factory.stdlib import DataclassDTO

@dataclass
class Foo:
    bar: str
    baz: str

@dataclass
class Bar:
    foo: Foo

config = DTOConfig(exclude={"foo.baz"})
dto = DataclassDTO[Annotated[Bar, config]]

@post(dto=dto, return_dto=None)
def handler(data: DTOData[Bar]) -> Dict[str, Any]:
    res = data.create_instance(foo__baz="world")
    assert res.foo.baz == "world"
    return res

Closes #1727
Pull Request Checklist

[ ] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

Description
Close Issue(s)

Looks good! A section about this feature in the docs would be nice I think.

Cheers! Yes, I will add to the tutorial and a How To section in usage docs before I close out.


solved #393

Description
added google image with login with google button
Related Issues
None
Type of PR

[enhancement] (x)

Screenshots / videos (if applicable)

Checklist

[X] I have gone through the contributing guide
[X] I have updated my branch and synced it with project main branch before making this PR
[X] I have performed a self-review of my code
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers, screenshots, and videos after making the changes.

Additional context:

@Anjaliavv51

@ChauhanAyush04 which issue is assigned to u?
mention the issue number in PR description

@ChauhanAyush04 which issue is assigned to u?
mention the issue number in PR description

Done


$::{'foo'} doesn't work

The problem
https://docs.perl6.org/language/packages#Direct_lookup

my $foo = 12;  say $::{'foo'};
===SORRY!=== Error while compiling:
Variable '$' is not declared  ------> ⏏$::{'foo'}

It applies to this version as well:

say $::<foo>;

(Both in REPL and as a program. )

perl6 -v
This is Rakudo version 2019.03.1 built on MoarVM version 2019.03

Suggestions
I don't know if it is supposed to work, so either change the documentation or
implement it (or file an error)
I think we can live without this syntax, as this works:

say ::{'$foo'};

The form itself is speculated in S02, but if it's not tested, well.

Variable '$' is not declared

The problem I see here is an LTA error, as the anonymous variable$ doesn't have to be declared, so the error doesn't even make sense.
Similarly,

$ perl6 -e 'my $foo = 1; $::("$foo");'
No such symbol ''
in block  at -e line 1
$ perl6 -e 'my $foo = 1; $::(q<$foo>);'
No such symbol ''
in block  at -e line 1

That's not accurate either, or very helpful, but at least it's talking about symbols.

Either way, it does not belong in the documentation.

Maybe it would be interesting to open an issue in Rakudo about the LTA error.


An error occurred using redisdb

An error occurred using redisdb
ERROR: 2024/10/29 21:38:12 logger.go:39: panic error: runtime error: index out of range [0] with length 0

got the same error by running the given sample


Try forcing forcing encoding before transcoding

Fixes #79 without new dependency of #199

Thanks @vmg, @mlinksva!


Register page.header render hook

This PR adds a new render hook between the title and actions in the page header.
A use case example is adding simple filter tabs in the same line with the title and actions instead of taking an extra space between the header and the page content.

[x] Changes have been thoroughly tested to not break existing functionality.
[x] New functionality has been documented or existing documentation has been updated to reflect changes.
[ ] Visual changes are explained in the PR description using a screenshot/recording of before and after.

I think the more appropriate name is panels::page.header.actions.before. Let's also add panels::page.header.actions.after


Voyage Guide GPT

Your virtual travel buddy here to help make your travel planning experience smooth, fun, and informative.
https://chat.openai.com/g/g-MDExvbFqe-voyage-guide

Merged


macOS keybase finder integration breaks on every system update

Keybase GUI Version: 5.7.0-20210622193735+e3826b703a
Settings -> Files -> Enable Finder Integration spins for a while, then stops; in the logs, it seems like
error	15:59:22.085079-0700	keybase.Helper	Remote encountered error: Error Domain=KMErrorDomain Code=28 "Loading extension(s): com.github.kbfuse.filesystems.kbfuse requires a reboot" UserInfo={NSLocalizedDescription=Loading extension(s): com.github.kbfuse.filesystems.kbfuse requires a reboot}

but there's no indication of this in the GUI
might be relevant.
It seems that this happens to me every time there's a security update.

Duplicate of #24636


[ruler] Ruler data is bit off.

Deduplicated query gives 2 series for single series (with and without replica label).

Found and fixed


updated my affiliations

Coverage remained the same at 39.018% when pulling a2ba99dec8676ccf0cefbd48ab0d07e964e258a8 on nterhoeven:develop into 6d86000c493129fe9c52d8fad2296688dc76ac10 on chloroExtractorTeam:develop.


iosevka: Simplify custom build process

Although hopefully this can eventually be added to nodePackages, it uses
some devDependencies to build custom fonts. Node2nix doesn't currently
support enabling devDependencies for a single package.

Got rid of redundant let-in statements.
node-packages.json now only pulls in Iosevka.
generate.sh

Uses a nix-shell shebang to ensure it builds using the current
version of node2nix (the old version caused some issues due to the
19.03 release version being 1.6.0 instead of 1.7.0).
Builds in development mode to fix the devDependencies issue.

Use the tree of the built node package as sourceRoot instead of
installing node dependencies manually. This means the source will have
to be updated in both node-packages.json and default.nix, but to make
things easier the derivation inherits the version number.
Disparate build options now all live under privateBuildPlan, which is
converted first with builtins.toJSON and then to TOML using remarshal
(Unfortunately there is not currently a builtins.toTOML, see NixOS/nix#2967).
Extra parameters can also be provided that will be converted to JSON
then TOML. This will overwrite the default parameters.toml file.

Motivation for this change
I was already working on bumping the version when the PR came in a few days ago, but I still had a few improvements I thought would help for the future! Making node2nix and remarshal do most of the work seemed like a good idea.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @cstrahan @jfrankenau @ttuegel @babariviere

@rileyinman You can also add yourself as a maintainer, if you want to.

Do you want me to force-push to squash these commits?

Don't worry, we can squash it with github. I cannot merge your PR but it's ok for me.

With suggestions from @hlolli in #68820, I can try merging the build deps into nodePackages. This would have the disadvantage of having to keep a package.json up to date with whatever Iosevka decides to do but would also mean no several-thousand line generated node file :P I personally wouldn't mind having the package.json be part of the update process, but what does everyone else think?

I went ahead and pushed the change up, let me know if there are any objections to this :)

Very good, this would be the way I would do it. It also locks iosevka's npm dependencies in 1 build dependency. So when bumping this package, it will be a ceremony to compare the package.json files and re-generate the node-packages. But ofc I recommend using node2nix locally for development. The only wart in this process is the fact that the package-name takes the relative local path, other than that, looks good to me :D

@hlolli do you have any ways the package name thing could be better? I just copied it off what you did in lumo

Thanks!


DataType.GEOMETRY not supported?

Creating a model with @Column(DataType.GEOMETRY('point')) such as:
  @Column(DataType.GEOMETRY('point'))
  public geo_location: {
    type: string;
    coordinates: [number, number];
  };

or
  @Column(DataType.GEOMETRY('point'))
  public geo_location: any

Upon trying to create a new model record with the specific field:
      geo_location: {
        type: 'point',
        coordinates: [latitude, longitude],
      },

is always generating the following error:
column "geo_location" is of type point but expression is of type geometry
The field type is point (as it should be) ... but for some reason sequelize-typescript seems to not propagate correctly the DataTypeGeometry parameters (type: string and srid?: number)
I'm following the instructions from http://docs.sequelizejs.com/variable/index.html

@ShaharHD Which sequelize version are you using?
With the following setup it is working well for me:
@Table
export class Location extends Model<Location> {
    @Column(DataType.GEOMETRY('POINT'))
    point: any;
}

Location.create<Location>({
            point: {
                type: 'Point',
                coordinates: [39.807222, -76.984722]
            }
        })

All latest versions.
    "sequelize": "^4.14.0",
    "sequelize-typescript": "^0.5.0",

I also have the following (if it makes any difference)
    "@types/sequelize": "^4.0.76",
    "sequelize-noupdate-attributes": "^1.0.0",

The other difference might be that I'm using Postgres and you're testing with a different DB?
I'll create a test project repo - and will update.

I've tested it on mysql and postgres. On both it is working. Can you provide a stack trace to your error as well?

@ShaharHD Same here? Did you get it to work? Can this issue be closed?

I confirmed @RobinBuschmann solution is working. The key is you need to use capital.
DataType.GEOMETRY('POINT')

Not
DataType.GEOMETRY('point')

The latter will cause error.
However, if the DataType.GEOMETRY() suppose to take case-insensitive. I think this considered a bug.

@micksatana thanks

This appears to be broken in the later versions of MySQL. Using the following packages:
"@types/sequelize": "^4.28.9",
"sequelize": "^5.22.3",
"sequelize-typescript": "^1.1.0",

And the following property as specified above
@Column(DataType.GEOMETRY('POINT'))
point: any;

And assigning it a value like
entity.point = {
    type: 'Point',
    coordinates: [row.longitude, row.latitude],
};

Will result in
FUNCTION GeomFromText does not exist
This is because MySQL deprecated and later on got rid of that function. It should be using ST_GeomFromText now.

Please am also getting this error and have looked for the solution everywhere and have not gotten any working solution. I created my table using
location: {
type:DataTypes.GEOMETRY('POINT', 4326),
allowNull:false
}
an I now query the table using this
const nearestLocation = await Address.findAll({
where: {
location:[[sequelize.fn('ST_Distance_Sphere', sequelize.literal('geolocation'), location),'distance']],
order: 'distance',
limit: 4
}
})
this is the location
const location = sequelize.literal(ST_GeomFromText('POINT(${long} ${lat})', 4326));
but this is returning error
Error: GeometryType undefined not supported. Please I really need help to get this solved


contributers.md merging conflict

It is saying,
"This branch has conflicts that must be resolved
Only those with write access to this repository can merge pull requests."
Screenshot -

@Rohitm619 I'll handle that...no need to create another issue


[CDN][2024-02-01] Refactor the inheritance hierarchy for rule actions and conditions to fix Pandora SDK const conflict

… and conditions to fix Pandora SDK const conflict
ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[ ] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[x] Other, please clarify:

Our existing swagger definition does not follow the best practice of polymorphism to define class inheritance hierarchy, a hard-coded property (typeName) with a single ENUM value is used in a lot of places for deserialization purpose. It will break the Hashicorp Pandora SDK generation which will impact Terraform integration for Azure Front Door Standard/Premium service. In our case, with so many ENUMs with the same name “typeName”, it will complain about const name conflict when generating Golang SDK: https://github.com/hashicorp/pandora/issues/2831. Azure SDK Track2 for Golang does not have the problem as they did some workaround to add prefixes when the name is conflicting, which is not recommended by Pandora team. This PR aims to refactor the inheritance hierarchy for rule actions/conditions to fix Pandora SDK const conflict.

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

@t-bzhan I have reviewed the PR changes and it looks like this is just changing the way polymorphism is described to be more in-line with Azure conventions, so I'm willing to approve the breaking changes at the REST API level. But I think you need to work with the SDK teams for any languages that are affected to minimize the impact there.

/azp run

ModelValidation errors need fixing, would be great to get that done before further ARM review

ModelValidation errors need fixing, would be great to get that done before further ARM review

Hi @TimLovellSmith , the ModelValidation errors are not related to this PR. Can we skip this step for now? I’ll submit a separate PR to address them after this one.

ModelValidation errors need fixing, would be great to get that done before further ARM review

Hi @TimLovellSmith , the ModelValidation errors are not related to this PR. Can we skip this step for now? I’ll submit a separate PR to address them after this one.

ModelValidation is required to fix before merge

ModelValidation errors need fixing, would be great to get that done before further ARM review

Hi @TimLovellSmith , the ModelValidation errors are not related to this PR. Can we skip this step for now? I’ll submit a separate PR to address them after this one.

ModelValidation is required to fix before merge

Hi @TimLovellSmith , I understand the importance of maintaining correct Swagger definitions. However, I find the model validation errors a bit confusing. Specifically, the first two errors seem contradictory. The first error indicates that I added an additional id field in the example because our Swagger doesn’t define it. On the other hand, the second error complains that I’m missing the id because the resource definition is marked as x-ms-azure-resource: true. I attempted to move the id into the properties, but that approach didn’t work either. Could you kindly suggest the next steps to resolve this?

I think having 'id' at the top level is the way to go but there might be something a bit 'off' with the way you are using x-ms-azure-resource actually. Just tagging your resource type with that doesn't give it any properties like 'id'. Instead, you should inherit from ProxyResource (or else TrackedResource).

    },

POST operations shouldn't normally return resources.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:2977 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

      "description": "Resource ID.",

What resource is it returning the ID of? a 'can migrate result' is not an azure resource.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:2969 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

  "x-ms-azure-resource": true

POST request bodies should not be marked as x-ms-azure-resource, except perhaps in the very UNusual case they're creating a new resource

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:3054 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

  "x-ms-azure-resource": true

[ARMBlockingComment] POST operations shouldn't normally return resources. Do you really need to return these properties? Consider deprecating or removing them, if not.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:3122 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

      "description": "Resource ID.",

of?

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:3108 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

  "x-ms-azure-resource": true

I assume your Origins are modeled as resources... and then you should ideally inherit ProxyResource instead of using this tag.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:5503 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

  "x-ms-azure-resource": true

This tag shouldn't be on the 'properties' property bag!
Please remove it, even if its breaking I'm convinced its incorrect enough to be a bugfix, as in nobody should be depending on it.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:5579 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

  "x-ms-azure-resource": true

If this is a proxy resource represented elsewhere in the API, then you can inherit ProxyResource.
Otherwise, I believe this tag shouldn't be there.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:5597 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

  "x-ms-azure-resource": true

Should be [ARMBlockingComment] if this were this a new API:
x-ms-azure-resource tag shouldn't be added on the 'properties' property bag deifnition!
Please remove it! ... Unless its too breaking.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:5632 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

},

Please remove these and everywhere you reference them, instead inherit "allOf", from ProxyResource, TrackedResource, or Resource in common-types' types.json
../../../../../common-types/resource-management/v6/types.json](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/common-types/resource-management/v6/types.json)

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:7082 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

"PrivateEndpointStatus": {

I'd recommend you remove this and instead use the definition here....
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/common-types/resource-management/v6/privatelinks.json
BUT...
It does not define the "Timeout" or "Pending" statuses. Are you sure you really return those, and that its okay to?
I think NRP depends on you using a known set of values.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:7097 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

},

Consider removing these and instead referencing the ErrorResponse definitions from common-types.
This feedback is more like 'optional' at this point, in case its breaking.

Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:7225 in dafbb66. [](commit_id = dafbb66d086ca156bd0b5f23e7a946dd2ce41431, deletion_comment = False)

Hi @t-bzhan, reasons for GO CI failure: CdnCertificateSourceParameters removes the service prefix (e: cdn) during the generation of the GO SDK, and it is generated as CertificateSourceParameters, so it conflicts with the newly defined CertificateSourceParameters, It is recommended that you rename it.

}

Optional, but since you're already making SDK breaking changes....
For sake of consistency with other RPs and reviewability, I would like to recommend removing these parameter definitions from your spec, and instead always referencing the ones from common-types.
e.g.
../../../../../common-types/resource-management/v6/types.json#parameters/SubscriptionIdParameter
Refers to: specification/cdn/resource-manager/Microsoft.Cdn/stable/2024-02-01/cdn.json:7251 in dafbb66. [](commit_id = dafbb66, deletion_comment = False)

Hi @t-bzhan, reasons for GO CI failure: CdnCertificateSourceParameters removes the service prefix (e: cdn) during the generation of the GO SDK, and it is generated as CertificateSourceParameters, so it conflicts with the newly defined CertificateSourceParameters, It is recommended that you rename it.

Thank you, @TimLovellSmith! Your comments are well received. There are several aspects we need to improve in our existing Swagger:

Remove the incorrect usage of ‘x-ms-azure-resource,’ especially in POST body and response.
For true Azure resources, inherit properties from ‘ProxyResource’ instead of using this tag directly.
For common definitions (such as ‘Resources’, ‘ProxyReference' and 'PrivateEndpoint’), we should  refer to them from a common place rather than defining them in the Swagger.

Given the extensive changes required, I have to discuss them with the feature owners and defer these improvements to the next PR.

Hi @t-bzhan, reasons for GO CI failure: CdnCertificateSourceParameters removes the service prefix (e: cdn) during the generation of the GO SDK, and it is generated as CertificateSourceParameters, so it conflicts with the newly defined CertificateSourceParameters, It is recommended that you rename it.

Hi @Alancer. Is there any specific reason for removing the prefix? In my opinion, keeping ‘cdn’ here is more appropriate. The ‘CdnCertificateSourceParameters’ is in contrast to ‘KeyVaultCertificateSourceParameters.’ While the former indicates that the certificate is managed by CDN itself, the latter implies that the certificate belongs to the customer’s key vault. Therefore, the prefix is not redundant. Is this prefix removal logic unique to Golang? Can we remove it?

Hi @t-bzhan, reasons for GO CI failure: CdnCertificateSourceParameters removes the service prefix (e: cdn) during the generation of the GO SDK, and it is generated as CertificateSourceParameters, so it conflicts with the newly defined CertificateSourceParameters, It is recommended that you rename it.

Hi @alancer. Is there any specific reason for removing the prefix? In my opinion, keeping ‘cdn’ here is more appropriate. The ‘CdnCertificateSourceParameters’ is in contrast to ‘KeyVaultCertificateSourceParameters.’ While the former indicates that the certificate is managed by CDN itself, the latter implies that the certificate belongs to the customer’s key vault. Therefore, the prefix is not redundant. Is this prefix removal logic unique to Golang? Can we remove it?

go language has one trait that use type with namespace which means each type in go is used as armcdn.CdnCertificateSourceParameters. you could see the cdn part is duplicate, so we will remove it in our codegen.

Hi @t-bzhan, reasons for GO CI failure: CdnCertificateSourceParameters removes the service prefix (e: cdn) during the generation of the GO SDK, and it is generated as CertificateSourceParameters, so it conflicts with the newly defined CertificateSourceParameters, It is recommended that you rename it.

Hi @alancer. Is there any specific reason for removing the prefix? In my opinion, keeping ‘cdn’ here is more appropriate. The ‘CdnCertificateSourceParameters’ is in contrast to ‘KeyVaultCertificateSourceParameters.’ While the former indicates that the certificate is managed by CDN itself, the latter implies that the certificate belongs to the customer’s key vault. Therefore, the prefix is not redundant. Is this prefix removal logic unique to Golang? Can we remove it?

go language has one trait that use type with namespace which means each type in go is used as armcdn.CdnCertificateSourceParameters. you could see the cdn part is duplicate, so we will remove it in our codegen.

Hi @tadelesh , I understand that removing the prefix would make the type name cleaner in most scenarios. However, in this specific example, armcdn.CdnCertificateSourceParameters conveys more than armcdn.CertificateSourceParameters. The latter doesn’t clearly indicate that the certificate is managed by CDN itself. To put it another way, we support multiple certificate sources: one from CDN (managed by CDN itself) and another from the customer’s key vault. I believe armcdn.CdnCertificateSourceParameters /armcdn.KeyVaultCertificateSourceParameters is more appropriate than armcdn.CertificateSourceParameters/armcdn.KeyVaultCertificateSourceParameters. The latter doesn’t fully convey the design intention.
Could we exclude this specific path from the prefix-removing logic?

Hi @t-bzhan, reasons for GO CI failure: CdnCertificateSourceParameters removes the service prefix (e: cdn) during the generation of the GO SDK, and it is generated as CertificateSourceParameters, so it conflicts with the newly defined CertificateSourceParameters, It is recommended that you rename it.

Hi @alancer. Is there any specific reason for removing the prefix? In my opinion, keeping ‘cdn’ here is more appropriate. The ‘CdnCertificateSourceParameters’ is in contrast to ‘KeyVaultCertificateSourceParameters.’ While the former indicates that the certificate is managed by CDN itself, the latter implies that the certificate belongs to the customer’s key vault. Therefore, the prefix is not redundant. Is this prefix removal logic unique to Golang? Can we remove it?

go language has one trait that use type with namespace which means each type in go is used as armcdn.CdnCertificateSourceParameters. you could see the cdn part is duplicate, so we will remove it in our codegen.

Hi @tadelesh , I understand that removing the prefix would make the type name cleaner in most scenarios. However, in this specific example, armcdn.CdnCertificateSourceParameters conveys more than armcdn.CertificateSourceParameters. The latter doesn’t clearly indicate that the certificate is managed by CDN itself. To put it another way, we support multiple certificate sources: one from CDN (managed by CDN itself) and another from the customer’s key vault. I believe armcdn.CdnCertificateSourceParameters /armcdn.KeyVaultCertificateSourceParameters is more appropriate than armcdn.CertificateSourceParameters/armcdn.KeyVaultCertificateSourceParameters. The latter doesn’t fully convey the design intention.
Could we exclude this specific path from the prefix-removing logic?

@Alancere please add go directive to rename CertificateSourceParameters to CertificateSourceParametersBase to unblock the pr.

/pr RequestMerge

Can you please check the model validation failures before requesting merge ?
Following required checks are failing:
❌ Swagger ModelValidation

Can you please check the model validation failures before requesting merge ?
Following required checks are failing: ❌ Swagger ModelValidation

Hi @raosuhas , as I mentioned in a previous comment reply, the model failures were not introduced by that change. Fully addressing them would require changes in multiple places, and there’s a chance that it could introduce breaking changes. I recommend resolving the issue in a separate PR. Does that make sense to you?

/pr RequestMerge

@raosuhas , can you help merge the PR?

/azp run

Hi @razvanbadea-msft, Is there anything I need to follow up on to get the PR merged?

Hi @razvanbadea-msft, Is there anything I need to follow up on to get the PR merged?

A required check is failing, it needs to be fixed before merging

Hi @razvanbadea-msft, Is there anything I need to follow up on to get the PR merged?

A required check is failing, it needs to be fixed before merging

Hi  @razvanbadea-msft , I think the Golang SDK failure should already be resolved, as we have renamed one of the properties that previously caused a conflict. You can refer the historical comments.

@Alancere @Alancere , can you help confirm?

/azp run

Hi @razvanbadea-msft, Is there anything I need to follow up on to get the PR merged?

A required check is failing, it needs to be fixed before merging

Hi @razvanbadea-msft , I think the Golang SDK failure should already be resolved, as we have renamed one of the properties that previously caused a conflict. You can refer the historical comments.
@Alancere @tadelesh , can you help confirm?

SDK azure-sdk-for-go CI passed


First request after a published version bump causes a failure to find package.

Description
The first request after a version bump causes a failure to find package. Subsequent requests result in successful queries.
Expected behavior
The very first request for a package following a version bump, should be successful. The cache/CDN logic should check upstream during a cache miss.
To Reproduce

Bump a version and publish.
Pip install from requirements.txt.
Observe an error is displayed.
Try again, observe success.

My Platform
Docker build process, extending the python:3.8.0-alpine docker image.

Hello @iMerica, are you still experiencing these issues?


Issue with install pytest-dependency

When I run pipenv install for a Pipfile that contains pytest-dependency package I get the following error:
Traceback (most recent call last):
  File "C:\Python36\Scripts\pipenv-script.py", line 11, in <module>
    load_entry_point('pipenv==8.2.6', 'console_scripts', 'pipenv')()
  File "c:\python36\lib\site-packages\pipenv\vendor\click\core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "c:\python36\lib\site-packages\pipenv\vendor\click\core.py", line 697, in main
    rv = self.invoke(ctx)
  File "c:\python36\lib\site-packages\pipenv\vendor\click\core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\python36\lib\site-packages\pipenv\vendor\click\core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\python36\lib\site-packages\pipenv\vendor\click\core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "c:\python36\lib\site-packages\pipenv\cli.py", line 1785, in install
    do_init(dev=dev, allow_global=system, ignore_pipfile=ignore_pipfile, system=system, skip_lock=skip_lock, verbose=verbose
, concurrent=concurrent, deploy=deploy)
  File "c:\python36\lib\site-packages\pipenv\cli.py", line 1293, in do_init
    do_lock(system=system)
  File "c:\python36\lib\site-packages\pipenv\cli.py", line 1083, in do_lock
    pre=pre
  File "c:\python36\lib\site-packages\pipenv\utils.py", line 421, in resolve_deps
    resolved_tree.update(resolver.resolve(max_rounds=PIPENV_MAX_ROUNDS))
  File "c:\python36\lib\site-packages\pipenv\patched\piptools\resolver.py", line 101, in resolve
    has_changed, best_matches = self._resolve_one_round()
  File "c:\python36\lib\site-packages\pipenv\patched\piptools\resolver.py", line 199, in _resolve_one_round
    for dep in self._iter_dependencies(best_match):
  File "c:\python36\lib\site-packages\pipenv\patched\piptools\resolver.py", line 293, in _iter_dependencies
    dependencies = self.repository.get_dependencies(ireq)
  File "c:\python36\lib\site-packages\pipenv\patched\piptools\repositories\pypi.py", line 171, in get_dependencies
    result = reqset._prepare_file(self.finder, ireq)
  File "c:\python36\lib\site-packages\pipenv\patched\pip\req\req_set.py", line 639, in _prepare_file
    abstract_dist.prep_for_dist()
  File "c:\python36\lib\site-packages\pipenv\patched\pip\req\req_set.py", line 134, in prep_for_dist
    self.req_to_install.run_egg_info()
  File "c:\python36\lib\site-packages\pipenv\patched\pip\req\req_install.py", line 438, in run_egg_info
    command_desc='python setup.py egg_info')
  File "c:\python36\lib\site-packages\pipenv\patched\pip\utils\__init__.py", line 707, in call_subprocess
    % (command_desc, proc.returncode, cwd))
pip.exceptions.InstallationError: Command "python setup.py egg_info" failed with error code 1 in C:\Users\my_username\App
Data\Local\Temp\tmprtpkxb6bbuild\pytest-dependency\

Python version: 3.6.3
Pipenv version: 8.2.6
Pip version: 9.0.1

Same here, but using Python 3.6.1 while trying to install matplotlib.

For pytest-dependency, it looks like it need pytest to be already installed in order to be able to build (the setup.py imports a module that imports pytest). That's not cool. That is why we get an error when trying to build.
That's an issue with the pytest-dependency package itself, there's not much to be done here IMHO.
The workaround: Always install pytest manually before installing pytest-dependency.
For matplotlib, I've messed around a bit and noticed that subprocess32. a py2 only dependency, is added while it should not, which causes the issue. I'm pretty sure it's fixed by #833, which should land when 8.2.3 gets released.

Thanks for all of your research @vphillippon! Yes, both of these issues are related to poorly written setup.py files by the distributors of these packages. Unfortunately, there isn't a lot we can do from our end. My only advice would be to prompt the package owner to determine a fix on their end.

For the record, with matplotlib, it's actually an issue with pipenv/piptools (fixed by #833, but not yet released) wrongly getting the dependencies from any wheel for any OS/python version, not sticking to the one for the current platform, ending up fetching some py2 dependencies even on py3. matplotlib did nothing wrong (even if their setup.py is beefy, the dependencies are allright).
Just to not blame the author of matplotlib here 😄


Car Schedule Table: Date Sorting By Day Prior to Month

The date in the table is being sorted by day prior to month.
Example:
01-05-2019 is before 02-04-2019

Yes that's a bug. I will take a look on it near weekend, as this might be more tricky.

Should be fine now - please recheck in free time.

Sorting seems fine.
Thanks @Volmarg

Thanks for recheck and reporing as well.


Failed to build in Heroku (node v6.10.2)

npm ERR! node v6.10.2
       npm ERR! npm  v3.10.10
       npm ERR! code ELIFECYCLE

       npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
       npm ERR! Exit status 1
       npm ERR!
       npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
       npm ERR! Make sure you have the latest version of node.js and npm installed.
       npm ERR! If you do, this is most likely a problem with the lwip package,
       npm ERR! not with npm itself.
       npm ERR! Tell the author that this fails on your system:
       npm ERR!     node-gyp rebuild
       npm ERR! You can get information on how to open an issue for this project with:
       npm ERR!     npm bugs lwip
       npm ERR! Or if that isn't available, you can get their info via:
       npm ERR!     npm owner ls lwip
       npm ERR! There is likely additional logging output above.

       npm ERR! Please include the following file with any support request:
       npm ERR!     /tmp/build_99265a0bab5ed98b6bb931306e82910b/MangooID-Back-End-753f7829e6307dcbe4d84626349eeba8d3af1861/npm-debug.log
-----> Build failed

       We're sorry this build is failing! You can troubleshoot common issues here:
       https://devcenter.heroku.com/articles/troubleshooting-node-deploys

       If you're stuck, please submit a ticket so we can help:
       https://help.heroku.com/

I have problem with node 6.10.2 too.
I have tested also with 4.7.3; does not build
4.4.7 works.
It is not related with Heroku.
I was running the script in a container

@alperozisik In case this helps you I had to downgrade to node 6.9.2 and npm 3.10.9 (matched my production to my development environment which I should have done since the beginning)
In Heroku the node js version the server uses is the same found in the package.js file under the engines property so I just changed that from
"engines": {
"node": "6.x"
}
to
"engines": {
"node": "6.9.2",
"npm": "3.10.9"
}
That fixed it for me because lwip always worked in my dev environment and used to work but stopped working in our prod environment.
Now, you may not be able to do that; I was able to because I'm the sole back end developer in the team and I knew any node 6 version will do. However if you can change the node and npm version as you like then I recommend to change to those settings.

Chiming in, also problems with 6.10.2 on my local.

Same problem here, builds with 6.9

Thanks for pointing me int he right direction @OussamaRomdhane . It seems heroku updated their engines.

Same problem here
`CC(target) Release/obj.target/lwip_decoder/src/lib/png/png.o
In file included from ../src/lib/png/png.c:14:0:
../src/lib/png/pngpriv.h:805:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the notes in pngpriv.h"
error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
^

lwip_decoder.target.mk:165: recipe for target 'Release/obj.target/lwip_decoder/src/lib/png/png.o' failed
make: *** [Release/obj.target/lwip_decoder/src/lib/png/png.o] Error 1
make: Leaving directory '[MY FOLDER]/node_modules/lwip/build'
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:285:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 4.4.0-72-generic
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd [MY FOLDER]/node_modules/lwip
gyp ERR! node -v v6.10.2
gyp ERR! node-gyp -v v3.6.0
gyp ERR! not ok
`
ubuntu 16.04.2
GNU Make 4.1
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

Same problem here (not with heroku)
CC(target) Release/obj.target/lwip_decoder/src/lib/png/png.o
In file included from ../src/lib/png/png.c:14:0:
../src/lib/png/pngpriv.h:805:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the notes in pngpriv.h"
error ZLIB_VERNUM != PNG_ZLIB_VERNUM
^
lwip_decoder.target.mk:165: recipe for target 'Release/obj.target/lwip_decoder/src/lib/png/png.o' failed
make: *** [Release/obj.target/lwip_decoder/src/lib/png/png.o] Error 1
make: Leaving directory '[MY FOLDER]/node_modules/lwip/build'
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:285:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 4.4.0-72-generic
gyp ERR! command "/usr/bin/nodejs" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd [MY FOLDER]/node_modules/lwip
gyp ERR! node -v v6.10.2
gyp ERR! node-gyp -v v3.6.0
gyp ERR! not ok
ubuntu 16.04.2
GNU Make 4.1
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

see #297

For the benefit of anyone else in search of a solution, your best bet may be to give jimp a try.  It has a similar (and sometimes simpler) API, with zero external dependencies, so no more struggling with node-gyp.
https://www.npmjs.com/package/jimp


Target debug_unpack_ios failed:  Exception: Failed to codesign

Steps to reproduce
I am not sure how we can reproduce it, but it started after installing firebase_core and firebase_messaing on my working project. Then I tried to start new project and I saw that my projects show the same error. However on simulators everything is ok. I am sure that directory is not cloud synced. Tried to delete flutter and install again.
Expected results
Started new project to test that it correctly will build and run
Actual results
None of my projects are running and shows this error
Could not build the precompiled application for the device.
Error (Xcode): Target debug_unpack_ios failed: Exception: Failed to codesign /Users/galix/StudioProjects/untitled2/build/ios/Debug-iphoneos/Flutter.framework/Flutter with identity 57209BF0C7BCADE6F2DD50416B02ABCE081826B7.

Logs
Logs
Waiting for iPhone (Galizhan) to connect...
Launching lib/main.dart on iPhone (Galizhan) in debug mode...
Automatically signing iOS for device deployment using specified development team in Xcode project: TF39AN734X
Running Xcode build...
Xcode build done.                                           11,7s
Failed to build iOS app
Could not build the precompiled application for the device.
Error (Xcode): Target debug_unpack_ios failed: Exception: Failed to codesign /Users/galix/StudioProjects/untitled2/build/ios/Debug-iphoneos/Flutter.framework/Flutter with identity 57209BF0C7BCADE6F2DD50416B02ABCE081826B7.

Error launching application on iPhone (Galizhan).

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.16.8, on macOS 14.1 23B74 darwin-arm64, locale ru-KZ)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.3)
[✓] VS Code (version 1.85.2)
[✓] Connected device (3 available)
[✓] Network resources

• No issues found!

Hello @galizhan
Could you confirm whether your project is located in a cloud-synced directory (like OneDrive or a similar one) or not? If so, this is similar to https://github.com/flutter/flutter/issues/123583.
Also, could you share the entire output of flutter run -v?
May be a duplicate of: https://github.com/flutter/flutter/issues/130639 (please also take a look at it and check if you have a such case as well)


Fix bugs in Pool

[x] tests and linter show no problems (npm t)
[x] code is properly formatted (npm run fmt)

Landed in https://github.com/metarhia/metautil/commit/f4814ebe1144ec78e4729f599c3b515bc56cc2d2


Error message in GuzzleClient.php: localization, relevancy and ux

Hi
3 suggestions for classes/GuzzleClient.php
The error message has to be localized so it can be translated in TB.
Moreover when the credit card number is wrong (wrong CVV for instance) we get the error "Could not connect with Stripe" but it is not relevant. Stripe is actually responding and throwing the card number error, so we should give a better error message to the user.
Last suggestion: can we get the error message INSIDE the checkout iframe instead of getting a whole page with just the error message. That way the user would stay on the checkout page and try again without having to go back to the cart. Conversion :)))

I would add https://stripe.com/docs/recipes/sending-emails-for-failed-payments for merchants and to increase ROI.

This was implemented as part of 1.7.0


Segfault when assertion incorrectly spelt

Laravel Version: 5.5.0
PHP Version: 7.1.7
Database Driver & Version: N/A

homestead-7: Checking for updates to 'laravel/homestead'
homestead-7: Latest installed version: 3.0.0
homestead-7: Version constraints: >= 3.0.0
homestead-7: Provider: virtualbox

Description:
I recently wrote a simple feature test that used a facade assertion, which I had (unknowingly) spelt incorrectly. When I ran phpunit, it resulted in a Segmentation Fault. Correcting the spelling of the assertion method name fixed the issue.
I don't understand segfaults very well, but when I googled how to debug it, I couldn't find anything in either the Laravel error log, or the nginx error log in homestead (/var/log/nginx/). I would have expected PHP to issue a function not found error (or similar) if I had spelt the method name incorrectly.
Steps To Reproduce:
This is being done inside homestead

Create a new feature test
Fake the queue: Queue::fake();
Attempt to call Queue::asertPushedOn('email', App\Jobs\SomeJob::class);
Run phpunit
(Hopefully) see segfault
Fix the assertion name to assertPushedOn()
Run phpunit - don't see segfault

Hopefully others can reproduce this as well. Please let me know if you need further information.

I've got Fatal error: Maximum function nesting level of '256' reached, aborting! in {myPath}/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php on line 120 instead of the segfault

Interesting why I got a segfault, and you got a nesting level error. Again, I'm not too knowledgable about segfaults so unsure why I'm getting it (aside from the method name being spelt incorrectly)

One of the most common causes of segfaults in PHP is infinite recursion. However, if you have Xdebug installed it will instead error out with a nesting level error.

Closing since it's not actually a bug in the framework.


[Windows] Cannot write to hosts with elevation/sudo

I've just installed the Windows x64 0.2.0 version of hostess (Windows 10), and it states it can't write to my hosts file, even when using sudo or an elevated console.
Any ideas as to what could be causing this?
PS: I've created a scoop app for this in my bucket.

Not all that familiar with Go, but I've managed to get as far as showing the actual error behind hostess not being able to write to the hosts file:
$ go run cmd/hostess/hostess.go fix
open C:\Windows\System32\drivers\etc\hosts: The parameter is incorrect.
exit status 1

After changing line 77 of commands.go to:
MaybeError(c, err.Error())

Have toyed around with this - again, not terribly familar with the language.
Lines 192+ of hostfile.go:
// Save writes the Hostfile to disk to /etc/hosts or to the location specified
// by the HOSTESS_PATH environment variable (if set). Due to Windows file locking,
// it's best to truncate the file before opening it for writing.
func (h *Hostfile) Save() error {
	err := os.Truncate(h.Path, 0);
	if err != nil {
		return err
	}

	file, err := os.OpenFile(h.Path, os.O_RDWR|os.O_APPEND, 0644)
	if err != nil {
		return err
	}

	defer file.Close()
	_, err = file.Write(h.Format())

	return err
}

This SO answer explains that Windows locks files, and that it would need to be truncated without an open handle. So the change above does just that.
Not sure if it impacts other platforms, and so I'm not submitting as a PR - please let me know if I should go ahead and do that.

@mikerockett Thanks for looking into this! The locking semantics you linked to seem a bit strange to me. This code worked on Windows 7 so I'm curious what has changed here in 10. I have not had a chance to look into this yet but I will take some time soon.
Did the fix you suggested work for you? It seems reasonable that this can work on any OS but if not we can put it behind a platform build flag. If you're not familiar with Go this can be a bit complicated but if you want to take a stab at it there is some information here.

@cbednarski - You're welcome. he suggested fix does indeed work. However, I think W10 has changed something somewhere because my hosts file wasn't actually working at after hostess converted it to the hostess-format. Where multiple hosts are defined on a single line (<IP_ADDRESS> host1 host2), only host1 would load. Because I was in a rush to fix something on a dev-site, I reverted to the original one-host-per-line format. Unable to check now as I'm on a different PC without my dev-stack.
I assume a platform build flag tells the compiler to build using specific code for a specific platform? (May sound silly to ask, but I haven't worked with non-runtime languages in a long time, having moved over to web-dev.)

The suggested fix does indeed work. However, I think W10 has changed something somewhere because my hosts file wasn't actually working at after hostess converted it to the hostess-format.

Oh also interesting. I may need to add a Windows-specific formatter in that case.

I assume a platform build flag tells the compiler to build using specific code for a specific platform? (May sound silly to ask, but I haven't worked with non-runtime languages in a long time, having moved over to web-dev.)

Correct. The Go compiler can be instructed to include a certain file only when compiling a Windows binary (for example). Simple example: docker_default.go has a build flag that says "only include this on not Windows" while docker_windows.go will only build when Go is compiling for Windows (based on the filename).
The other way to do this is to use a runtime check for the OS name. I do this currently to set the default host file path. If the implementation starts to get messy with an if block that's a good hint that the build flag is a better approach.

Thanks for the info - handy to know. If I garner some time, it would be a god idea for me to play around with Go - looks like a great language to work with.

The other way to do this is to use a runtime check for the OS name. I do this currently to set the default host file path. If the implementation starts to get messy with an if block that's a good hint that the build flag is a better approach.

I'd naturally think a build-flag is better for this case. Considering the potential complexity here, you'd be far better off than me in doing a platform-specific change here. Having briefly looked at the code, I can imagine that changing the formatter for Windows is perhaps not as simple as a one-line-amendment...

This worked for me. If you don't open for append then sharing flags don't matter. (I think)
These kind of e_access_denied in windows are usually not real locks.
func (h *Hostfile) Save() error {
	file, err := os.OpenFile(h.Path, os.O_RDWR, 0644)
	if err != nil {
		return err
	}
	defer file.Close()

	err = file.Truncate(0)
	if err != nil {
		return err
	}

	_, err = file.Write(h.Format())

	return err
}

I took a slightly different approach and rewrote Save() to use an atomic update strategy instead of truncating the file. I have not had a chance to test it in various environments yet but theoretically this is the best approach.
https://github.com/cbednarski/hostess/compare/atomic-update

Where multiple hosts are defined on a single line (<IP_ADDRESS> host1 host2), only host1 would load. Because I was in a rush to fix something on a dev-site, I reverted to the original one-host-per-line format. Unable to check now as I'm on a different PC without my dev-stack.

Btw I also looked into this (did some simple editing with Notepad.exe) and multiple hostnames on the same line were picked up OK. I tested with ping. If you have more info about this let me know!

I tried the atomic-update branch.
When the file is replaced the permissions change and the whole thing breaks.
To make the hosts file work again I went to the advanced security tab on the file. Enabled inherited permissions, removed the files own permissions, and then flush the dns cache to trigger an update.
Probably replacing the file breaks the watch on the file. and without the correct permission set, whatever is watching the file doesn't watch the new file.
I don't think replacing the file will work because the system has a watcher with an open handle, so even if the permissions are set correctly it will probably still loose the watcher handle until the next flush or cache timeout.

@tdaniely Thanks for testing and following up! Your feedback is super helpful. The permissions thing is something I had not considered so I will likely need to add some platform-specific code here for Unix vs. Windows. I will try to get to this in the next few days.

Thanks all for the reports and suggestions. This fix is now live on master and tagged in 0.4.1. Sorry this was open for so long. 😬


Check kernel version for netif_rx_ni()

According to this patch [1], kernel developers
prepared to replace netif_rx_ni() with netif_rx(). They modified netif_rx() and implement
netif_rx_ni() as a wrapper of netif_rx().
In the following patch [2], netif_rx_ni() was
removed. This patch was mentioned in networking
changes for 5.18.[3]
For the compatibility, I check kernel version
before calling netif_rx_ni().
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Thank @quantabase13 for contributing!

Thank for your quick response and patience too.


Update acktest and rename TestBootstrapResources

Description of changes:

Updated acktest to remove typo in deserialize
Renamed TestBootstrapResources to BootstrapResources so pytest will stop complaining that it's not a test class

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

/lgtm


WIP: terraform openstack

Nice !
Let me check the deployment on teuto.net's platform.
I'll do that this evening

Couple of small things I saw at first blush:

I think we should also add the ability to support a dynamic number of etcd nodes.

We probably shouldn't ship with our own version of terraform.py. Seems like less maintenance for us if we just show folks where to pull it down from.

Probably need a .gitignore for *.tfstate* files. Likelihood for some of that info to be private for some folks.

I actually wanted to do totally seperate etcd nodes and have 3 resizable server resources "etcd" "k8s_master" and "k8s_node" but had a bunch of issues with the seperate nodes so I was going to work on doing that seperately and making it work then updating the terrform.

I really think we need to have a batteries included ...   I dislike users having to go off and download extra stuff.   I also modified it slightly to be able to pass groups via metadata that match our expectations.

yup, good call.  will add that.

I was having some issues a couple of days ago w/ separate etcd as well. I added a PR then that seemed to resolve the problem. May work out for you now!

@paulczar what do you think is missing to this PR ?

Merging it, we'll do another pull request if we want to manage the network stuff


DoDont instances without specified type

Description
Still some DoDont instances without specified type

Steps to reproduce

https://next.carbondesignsystem.com/libraries/carbon-react/latest/assets/accordion/usage#alignment Notice DoDont cards with black x icon


Release a "release" on each project once target is merged

This will make sure that the projects are properly tagged.
Related to #19
Signed-off-by: Mike Kolesnik<EMAIL_ADDRESS>

@tpantelis @skitt  ^

This was merged as part of #34


Change language of Gradle scripts in templates from Groovy to Kotlin

Use case
Since 3.22, Flutter supports writing Gradle buildscripts in Kotlin, in addition to Groovy.
Using Kotlin instead of Groovy in Gradle buildscripts has many advantages and has been recommended by Gradle since April 2023 (link).
I think it makes sense to make Kotlin the default language, to bring those advantages to every Flutter developer, many of whom are understandably not experts in Gradle, Groovy, and their quirks.
Proposal
Scope:

Change the language of files in Gradle templates from Groovy to Kotlin
Revise existing documentation on flutter/website to make sure it works equally well for both Groovy and Kotlin templates.

As for bullet point (2), it's worth noting that in many cases, Kotlin syntax in Gradle is a subset of Groovy syntax, so we in many cases we can just show Kotlin syntax and it'll work the same in Groovy, e.g.:
Example 1
This works only in Groovy:
dependencies {
    implementation "com.example:my-artifact:1.2.3"
}

but the following works both in Groovy and in Kotlin:
dependencies {
    implementation("com.example:my-artifact:1.2.3")
}

Example 2
This works only in Groovy:
android {
    namespace "pl.baftek.discoverrudy"
    compileSdk 34

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_11
        targetCompatibility JavaVersion.VERSION_11
    }

    kotlinOptions {
        jvmTarget "11"
    }

    defaultConfig {
        applicationId "pl.baftek.discoverrudy"
        minSdk 23
        targetSdk 34
        versionCode flutter.versionCode()
        versionName flutter.versionName()
    }
}

but this works in both:
android {
    namespace = "pl.baftek.discoverrudy"
    compileSdk = 34

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }

    kotlinOptions {
        jvmTarget = "11"
    }

    defaultConfig {
        applicationId = "pl.baftek.discoverrudy"
        minSdk = 23
        targetSdk = 34
        versionCode = flutter.versionCode()
        versionName = flutter.versionName()
    }
}

Alternatively, we might decide to provide users with a switch when calling flutter create, e.g. flutter create --android-build-language kotlin and flutter create --android-build-language groovy.
See also
https://github.com/flutter/flutter/issues/148586

Alternatively, we might decide to provide users with a switch when calling flutter create, e.g. flutter create --android-build-language kotlin and flutter create --android-build-language groovy.

Template combinatorics are very painful for us to maintain. Is there a compelling need to support Groovy in the template?

Is there a compelling need to support Groovy in the template?

I don't think so.

Template combinatorics are very painful for us to maintain.

I agree with this and would also prefer not to have to support both Groovy and Kotlin

Removed team tool because I think this has to happen by the android team with tooling support given the expertise required.

@reidbaker I think you misunderstood the issue; I might've not explained it well enough, sorry.
The scope is to only change the language of Gradle files in brand new app, created with flutter create, from Groovy (build.gradle) to Kotlin (build.gradle.kts)

We have done some prework to handle this situation including adding a kotlin linter.

I don't see how it's related to this – but I guess you mean we added linter to check the Flutter Gradle Plugin itself.

It would only have been related if this bug was tracking migrating the tooling we write in the flutter-tool to kotlin. Which is what I thought this bug was about.

@gmackall FYI Bartek is starting this work.

Reopening this since the initial PR was reverted


Sync updated user information from platform-core db to keycloak storage

Tested out the update user api of keycloak
POST http://sso.prod-preview.openshift.io/auth/realms/fabric8-test/account
Authorization: Bearer <TOKEN>
Accept: application/json, text/plain, */*
Content-Type: application/json

{
"firstName": "Shoubhik",
"lastName": "Bose",
"username":"somenameAnnotemail",
<EMAIL_ADDRESS>"attributes":
     {
         "bio":"my bio"
     }
}

This gets me a 200OK
To verify:
GET http://sso.prod-preview.openshift.io/auth/realms/fabric8-test/account
Authorization: Bearer <TOKEN>
Accept: application/json, text/plain, */*
Content-Type: application/json


docker-compose build && docker-compose up is throwing error

I am trying to deploy delta-reporter on Windows 10 docker. It is failing with error -
My env -
OS : Windows 10
Python : 3.9.4
WARNING: The HOME variable is not set. Defaulting to a blank string.
db uses an image, skipping
redis uses an image, skipping
rabbit uses an image, skipping
Building delta_core
[+] Building 5.1s (10/15)
=> [internal] load build definition from Dockerfile                                                                                0.0s
=> => transferring dockerfile: 32B                                                                                0.0s
=> [internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [internal] load metadata for docker.io/library/python:3.7-alpine                                                                                2.1s
=> [internal] load build context                                                                                0.1s
=> => transferring context: 3.89kB                                                                                0.0s
=> CACHED [base 1/1] FROM docker.io/library/python:3.7-alpine@sha256:56cb9e22b1ab2264251c111144f22a2bc83d2404ca30bf4237178f49703ebbb8                                                                        0.0s
=> CACHED [builder 1/5] RUN mkdir /install                                                                                0.0s
=> CACHED [builder 2/5] RUN apk update && apk add postgresql-dev gcc musl-dev                                                                                0.0s
=> CACHED [builder 3/5] WORKDIR /install                                                                                0.0s
=> CACHED [builder 4/5] COPY requirements.txt /requirements.txt                                                                                0.0s
=> ERROR [builder 5/5] RUN pip install --install-option="--prefix=/install" -r /requirements.txt                                                                                2.8s

[builder 5/5] RUN pip install --install-option="--prefix=/install" -r /requirements.txt:
#10 2.363 /usr/local/lib/python3.7/site-packages/pip/_internal/commands/install.py:232: UserWarning: Disabling all use of wheels due to the use of --build-option / --global-option / --install-option.
#10 2.363   cmdoptions.check_install_build_global(options)
#10 2.363 ERROR: Location-changing options found in --install-option: ['--prefix'] from command line. This is unsupported, use pip-level options like --user, --prefix, --root, and --target instead.

executor failed running [/bin/sh -c pip install --install-option="--prefix=/install" -r /requirements.txt]: exit code: 1
ERROR: Service 'delta_core' failed to build : Build failed

Hey @abhaybharti
Thanks a million for bringing this to our attention, I'm really sorry that it took us so long to see the issue.
The project is still quite green, so we expect to reply faster as we continue to improve our processes.
This issue got fixed on this PR: https://github.com/delta-reporter/delta-core/pull/66
Kind regards


useChat hook returns messages that only sent by me.

Select which package(s) are affected
@livekit/components-react
Describe the bug
chatMessages should give all the messages has been sent from all users
It was working before and after recent update it's not working properly. In the logs i can see that i receive the message but chatMessages is not updates itself.

Reproduction
I tried to create the simplest example here. Note that i entered livekit room credentials as dummy text.
https://stackblitz.com/edit/react-amx31c?file=src%2FApp.js
Logs
No response
System Info
no response

Severity
blocking an upgrade
Additional Information
No response

Thank you everybody! 🙏🏻


Line wrap

[x] Added an entry to CHANGELOG.md if this change could be valuable to users

Not done yet! But almost...
I'll probably just have to collapse the commits or something. There's a lot of in-progress stuff in there that aren't really useful intermediate information or useful intermediate builds.

General Introduction:
This uses cosmic-text's line-wrapping to allow us to wrap at some width, whether viewport or specifically written width.

Currently, there is no column wrapping! Cosmic-text does not seem to support this, I believe it wouldn't be hard to implement... but do that in a separate PR.

This introduces a Lines structure in visual_line.rs.
Lines is per EditorViewData, and stores the text layouts for that view. It provides a variety of functions for iterating over the lines in the editor by how they are wrapped.
There are two new ways of talking about lines: VLine (Visual Line) and RVLine (Relative Visual Line).
VLine is whatever the actual position (sortof index) the line (or piece of a wrapped line) is at. This can be expensive to compute because it essentially requires looking over all the positions previously. Usually, it is not needed, but it is needed for computing ScreenLines.
RVLine is the more typical structure. It is essentially a (line, line index) pair. The line is the typical buffer line, and the line index is the wrapped line it refers to.
Think of:
1 | this is a wrapped
    |  line
2 | this is a line

Then the first displayed line ("this is a wrapped") has a buffer line of 0, a VLine of 0, and an RVLine of (0, 0)
The second displayed line (" line") has a buffer line of 0, a VLine of 1, and an RVLine of (0, 1). Since it is the second part of the overall buffer line.
The third displayed line ("this is a line") has a buffer line of 1, a VLine of 2, and an RVLine of (1, 0).
Essentially, for line wrapping, we have to break the one-to-one translation between the VLine (line positioned in the display) and the buffer line. You can still do vline * line_height to get the position in the screen.
RVLine is what is typically used, because most of the code does not care about the absolute position information. Ideally, most code should rarely deal with VLines.

Most positioning logic now has to take care of affinity. CursorAffinity is what decides where to place the cursor when one offset has potentially multiple positions.
Like how at the end of a wrapped line, the very end is the same offset as the start of the next piece.

Other changes:

Diff's vline is now referred to as y_idx, because currently, it does not actually necessarily match up with a real line.

But I think it might be a good idea to have Lines keep track of this in the future, as a general arbitrary space-taking widgets features

ScreenLines is now cached in a kinda wacky manner. I have comments detailing it, but I should rewrite them to be more explanatory.

ScreenLines is more expensive to compute, since it has to work with vlines (turning the viewport.y0 into a vline, because there may be any number of wrapped lines above it)

This allows inlay hints and error lens to be multiline

Error lens is behind an option. I don't think I added one for inlay hints, but nobody does multiline inlay hints

Possible issues:

I have a variety in my notes that I plan to fix
Our fork of cosmic-text needs the line-height to be fixed, it is positioning incorrectly for wrapped lines
Diff behavior might have changed because I got rid of actual_line and visual_line
I should really test on big large files! It may be that there's some big problem due to using vlines that it dislikes, but I really hope it doesn't have issues.

It seems fine on limited tests. There's certainly room for improvement, but I really want to throw the editor code under benchmarks for that.

Need to ensure the DAP PR stuff works
Need to readd the IME code, I removed it temporarily, and install an IME so I can test it
There may be some screen lines cache issues lurking... I sometimes run into hard-to-reproduce annoyances.

I haven't run into these much now that batch was added, though I wouldn't be surprised if there are a couple more lurking
Addendum: still occasionally running into an issue where the scroll just stops working until you type a key. And then it continues.. not working. I remember adding logs for this bug previously and it seemed like the signal which should run never did. I'm very confused and this is hard to trigger deliberately.

TODOs (for the future):

Diff does not currently do any wrapping

I can see how I'd structure this, but I don't wanna do it in this PR, so it has wrapping disabled.
(To do the synchronization between both sides it needs to do the positioning logic with access to both editors)

We need to implement some sort of wrapping avoidance for really long lines

Ideally along with some other PR that just makes really long lines work nicely even without wrapping...

It would be nice to have a wrapping style that is like min(editor-width, wrap-column). So you can keep it to an expected column limit, while also keeping everything within view
We may want to extend the font sizes provides to also provide line-heights?

I think this mostly depends on how we integrate things like LSP code lens, whether that goes into Lines with special handling or some really weird wrapper. I'm leaning towards into Lines, via some generic 'special object insertion method' that works for Diff.

Indent when wrapping. Cosmic-text doesn't support this automatically, but I think it wouldn't be too hard to add ourselves or upstream to cosmic-text.
Indent multiline error lens, I think this would appear better

Possibly with a fancy line indentation

Limit multiline error lens length, some languages/LSPs just spam them because you don't usually see them all in the editor
Implement Copilot as a plugin
Way more tests for various multiline phantom text and friends
Maybe try to modify cosmic-text to have a better API for iterating over parts of lines :)))))
Eventually, get rid of the hacky code that compensates for cosmic text currently stripping a single space at the end of a wrapped line
Various todos littered around
Cosmic seems to sometimes wrap things like     Some(blah) to the next line, like one blank line and then the Some(blah), which seems undesirable
I think SelRegion should probably an affinity for start/end, but propagating it through all the logic is uh.... unpleasant
ScreenLines gets recomputed a bunch of times if you edit things, it should be smarter!

I think having batch for signals would help, but I also think this is due to multiple relevant signals getting updated when something changes that might not be easily batched...
There's certainly stuff I could do about being smarter when we clear things, but hopefully, there's some nice elegant way to do better.

I squashed all my commits because that made rebasing significantly easier. I likely would have had to do it anyway.
(I need to look through things that #2803 does and make sure I replicate how that fixes things, since I had to change pieces like I changed the previous impl to make it work; I may have missed/broken some piece of that.)

I'm not sure of the right way to make the vim-like block selection behave.
(in nvim):

So by default it seems like it goes by the line-index rather than per screen/visual line. Thinking of just putting this off to the future...

Line height in cosmic-text still needs to be fixed
I still want to go through a bunch of my code and todos and clean it up

Mostly fixes #945–we are missing various pieces of wrapping (column wrapping, indentation of wrapped lines, etc) but those can be broken out as separate issues.


Burst-fire weapons

Would be nice.
Also ties into improvements to guns like #1867
I want my G11

For reference for anyone looking at this it's already in but no guns actually use it as a default (main reason is no hotbar to change fire mode).

Yes, i'll probably add a few myself, but they'll be stuck on burst-fire.


Made NameWidget replace " " with "_" automatically.

As suggested by Mr Vroeijenstijn.

Should we have a test?

In this case that would be quite non-trivial, as we'd need to simulate keystrokes on the widget, and at the qt level rather than at the GafferUI level. I would like better test coverage for the UI and do my best when there are public APIs to be tested, but in this case any tests would have to have so much knowledge of the internals that I think it's a bit prohibitive really.


Adding Primer to list of servable packages

FWIW, this is working around the fact that the conditional styling on the new embed relies on loading some CSS on the fly from primer_css, which was previously vulcanized into embed-new.html. We need to consider whether to take out vulcanize when Polymer makes its exit or refactor the theming code.