[FLINK-17536] Change the config option of slot max limitation to slot…

…manager.number-of-slots.max

What is the purpose of the change
Change the config option of slot max limitation to slotmanager.number-of-slots.max
Brief change log
Change the config option of slot max limitation to slotmanager.number-of-slots.max
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

cc @GJL


 This totally breaks the debugging for us Corporate users that are behind all kinds of security systems. Please Fix ASAP.

I totally disagree with this NonXMLResponseError error approach. The errors I am experience have to do with low level proxy, firewalls, certificates of authority, and NonXMLResponseError outright masks the error. These errors happen long before any communication has happened with Tableau Server.

The issue I was trying to solve is that the current error handling code assumes you can parse one of our XML payloads with a specific set of tags and attributes.
ServerResponseError will throw a fairly gross stack trace if we revert this and you get an error from the Metadata API endpoints.
What I can do, is try to parse the XML, fail, and reraise the original exception

First thing is first. Fix the import on
https://github.com/tableau/server-client-python/blob/master/tableauserverclient/server/endpoint/endpoint.py#L1
You need to import NonXMLResponseError

Agreed, I pushed a fix in https://github.com/tableau/server-client-python/pull/515, it's in development now (where you can pull from to verify) -- we're discussing a patch release to master shortly as well.

I'm going to close this based on the end of the discussion where Tyler added the fix to import that error properly.


⚠ Bofrost.de has degraded performance

In 6381dfa, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 945 ms

Resolved: Bofrost.de performance has improved in a1046a6 after 6 minutes.


Update Developer Guide (Clear)

Write out implementation and design details for clear command in the Developer Guide.

Fix by #92.


Add hyperlinks field and urls index

This is required for cofacts/rumors-api#41

Thanks! I'll merge now


Survey Question: measurable categories not appearing when chosing a measurable tree q

Description

Waltz Version
1.50
Steps to Reproduce

...
Expected Result
No response
Actual Result
No response

This cannot be recreated.  Suspect it was a failed copy of test data.


Support C-style enums

It would be nice to support C-style enums both from Rust to C++ and C++ to Rust.
The former is straightforward, but for the latter we must handle C++ code that passes values outside the expected range (which is illegal in Rust).  We can do this by auto-generating a conversion function that checks whether the value from C++ is one of the expected values and aborting otherwise.
The #[non_exhaustive] attribute is a possibility instead of a conversion function, but I believe it would not help at the moment (as both the definition and uses are in the same crate).

I am interested in supporting this better. Currently my work codebase is static_casting to primitives and back, which works but can get pretty heavy on syntax.
#[non_exhaustive] isn't a direct solution even across crates because it's still UB for the enum to have any value other than the defined ones at runtime. For example the size of #[non_exhaustive] enum E { Only } is 0 bytes because there is only one possible runtime value.

In that case, should we go with a conversion function (at least for now)?

I think the most appropriate correspondence would be like this:
enum class SmallPrime: uint16_t {
  Two = 2,
  Three = 3,
  Five = 5,
};

#[derive(Copy, Clone, PartialEq, Eq)]
#[repr(transparent)]
pub struct SmallPrime(u16);

#[allow(non_upper_case_globals)]
impl SmallPrime {
    pub const Two: Self = SmallPrime(2);
    pub const Three: Self = SmallPrime(3);
    pub const Five: Self = SmallPrime(5);
}

This works exactly like a nonexhaustive enum but matches the foreign representation.
fn demo(p: SmallPrime) {
    if p == SmallPrime::Five {
        /* ... */
    }

    match p {
        SmallPrime::Two => {}
        SmallPrime::Three => {}
        SmallPrime::Five => {}
        _other => {}
    }
}

Implemented in #170.


[Issue] Just Enough Resources finds the villager trade for ME brdge when AE is not installed

Describe
Assuming that the RS bridge has one too I would assume that the ME one should also be removed when AE is not installed.
(I have neither installed)
Reproduce
Steps to reproduce the behavior:

In an environment without AE and RS, look up the bridge recipes in JEI with Just Enough Resources
note that the ME bridge has a villager trade 'recipe' but the RS one doesn't

...
Screenshots/Videos

Versions:

Forge version: 36.1.0
AdvancedPeripherals version: 0.6r

Crashlog/log (Use https://paste.gg or https://pastebin.com to upload your crashlog/log)
https://gist.github.com/Lupus590/1aff09cc86b72d99f9fc96cd7c4fc83a

Could you send me the full text there? I want to add that to the language files.

entity.minecraft.villager.advancedperipherals:computer_scientist

Fixed in 0.6.1b


Roll Flutter Engine from b0d97ba45f46 to dc8618da9eb0 (3 revisions)

https://github.com/flutter/engine/compare/b0d97ba45f46...dc8618da9eb0
2023-07-28<EMAIL_ADDRESS>Roll Skia from 5403af73dfef to f2362d22abcf (1 revision) (flutter/engine#44094)
2023-07-28<EMAIL_ADDRESS>Roll ANGLE from 179924cbfaf3 to 613eefa3a70f (1 revision) (flutter/engine#44093)
2023-07-28<EMAIL_ADDRESS>Roll Dart SDK from e851b8e49ade to aab0233f76b7 (2 revisions) (flutter/engine#44092)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jonahwilliams@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Flywheels crashes game with create mod

crash-2021-12-10_23.47.21-client.txt
Game crashes when Create contraption is overstressed.

Only when it's overstressed? This crash looks like #56 otherwise

Only when it's overstressed? This crash looks like #56 otherwise

it seems to happen when its not overstressed as well

Ah thanks for clarifying. Duplicate of #56


Test results output contains wrong name of the skipped requests

If a test is skipped, TEST RESULTS tab shows the message indicating that the test was skipped, but instead of the test/request/response name, it uses the hard coded value of  skippedrequest, e.g.:

Instead of Test skippedrequests is skipped, it should say something like Request is skipped or Tests are skipped Request 'Demo test Z' is skipped or something like this (I think Request is skipped makes most sense, since it may have no tests associated with it).
P.S. Love that this message is displayed in the TEST RESULTS and love the TEST RESULTS output. Now, instead of switching between various output logs, the TEST RESULTS output is the only output I check 90% of time (with exception of cases when I need to check responses for troubleshooting). Thanks a lot for this. Really handy.

Message already changed to Test skipped

I did notice. Looks good. Thank you.


discrepancy with toolchain on builds on same OS & Arch

We are using toolchain_llvm to try and bring reproducibility for C/C++ compilation however we've hit some oddities across two developer laptops.
I'm struggling to find the cause of the delta.
MODULE.bazel
llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm")
llvm.toolchain(
   llvm_version = "16.0.0",
)

use_repo(llvm, "llvm_toolchain")
register_toolchains("@llvm_toolchain//:all")

We are building libjpeg
https://github.com/freedesktop-unofficial-mirror/libjpeg/
load("@rules_cc//cc:defs.bzl", "cc_library")

genrule(
    name = "jconfig",
    srcs = [
        "jconfig.cfg",
        "jcmaster.c",
        "install-sh",
    ],
    outs = ["jconfig.h"],
    # Why do we need '-ansi' ?
    # Well to build with clang on macos or with the toolchain below we have to set it.
    # libjpeg is very old and predates C99 when you didn't even have to write return statements or return types.
    # Here was the error without it:
    # configure:626:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
    #    main(){return(0);}
    #    ^
    #    int
    #    1 error generated.
    #    configure: failed program was:
    #    #line 625 "configure"
    #    #include "confdefs.h"
    #    main(){return(0);}
    cmd = "$(location configure) --srcdir $$(dirname $(location jconfig.cfg)); cp jconfig.h $(@)",
    toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"],
    tools = ["configure"],
)

cc_library(
    name = "libjpeg",
    srcs = [
        "jcapimin.c",
        "jcapistd.c",
        "jccoefct.c",
        "jccolor.c",
        "jcdctmgr.c",
        "jchuff.c",
        "jcinit.c",
        "jcmainct.c",
        "jcmarker.c",
        "jcmaster.c",
        "jcomapi.c",
        "jconfig.h",
        "jcparam.c",
        "jcphuff.c",
        "jcprepct.c",
        "jcsample.c",
        "jctrans.c",
        "jdapimin.c",
        "jdapistd.c",
        "jdatadst.c",
        "jdatasrc.c",
        "jdcoefct.c",
        "jdcolor.c",
        "jddctmgr.c",
        "jdhuff.c",
        "jdinput.c",
        "jdmainct.c",
        "jdmarker.c",
        "jdmaster.c",
        "jdmerge.c",
        "jdphuff.c",
        "jdpostct.c",
        "jdsample.c",
        "jdtrans.c",
        "jerror.c",
        "jfdctflt.c",
        "jfdctfst.c",
        "jfdctint.c",
        "jidctflt.c",
        "jidctfst.c",
        "jidctint.c",
        "jidctred.c",
        "jmemmgr.c",
        "jquant1.c",
        "jquant2.c",
        "jutils.c",
    ] + [
        # This implementation uses memory to store so it's extremely portable
        # consider alternate implementations if you need to reduce memory usage.
        "jmemnobs.c",
    ],
    hdrs = glob(["*.h"]),
    includes = ["."],
    visibility = ["//visibility:public"],
    copts = [
        "-v"
    ]
)

The code is written in C90 which supports "implicit-int".
Oddly on my machine, the code compiles correctly but on another it fails when hitting functions with implicit-int.
The solution at the moment is to turn off that check or add "-ansi" to copts but I'm left wondering why it's not consistent across our two machines.
We collected the compiler output to track differences if there was different flags being set and I couldn't see anything meaningful that would cause it.
https://www.diffchecker.com/390Vul86/
(The diff does show that the toolchain is being picked up)

I'm not sure I'm following; when you say you end up needing to add -ansi to copts do you mean for the libjpeg target or for the jconfig genrule?
Regardless I suspect the issue here is that your configure script is using your host compiler instead of toolchains_llvm's compiler — adding to the toolchains attribute adds make vars that can be referenced in cmd but it doesn't automatically set env vars for these variables. Maybe try something like this?
-    cmd = "$(location configure) --srcdir $$(dirname $(location jconfig.cfg)); cp jconfig.h $(@)",
+   cmd = "CC='$(CC) $(CC_FLAGS)' $(location configure) --srcdir $$(dirname $(location jconfig.cfg)); cp jconfig.h $(@)",

Alternatively this might be a good use case for rules_foreign_cc.

Shoot.
The example I put above is missing the $(CC) for configure but then I found that the building of the library afterwards had a similar error.
I set action_env PATH and the error was reproduced on my machine.
It makes me believe there is something during cc_library that's picking up from the host as well even though I'm using toolchain

Hmm. Is the repo where you have this target public? Also are you able to share what $PATH was set to when you reproduced the error on your machine?
You can prevent host env vars from leaking into the build by setting --incompatible_strict_action_env but in this case I'm struggling to understand how different $PATHs could result in the error you're seeing. The -v output you shared shows that the clang from toolchains_llvm is being invoked; from there $PATH can influence what additional tools are invoked (i.e. ld64) but that's not what's happening in this case (error is coming from the compiler invocation itself).

Closing the loop here:
I need to set CC_FLAGS but for that to work, I needed a different toolchain than what's listed in the doc.
This was causing the ./configure script  to generate a different header file.


Use regular install for CI tests

The CI tests are now installed with a regular pip install, rather than being installed editabally. This ensures they are more realistic.

[ ] Investigate why the coverage has dropped because of this. (It seems the CLI tests are being missed.)

Probably the thing to do is to ditch the end-to-end CI tests, just keeping the --help one for validating that the cset command still works, and instead test the code inside __init__.py more explicitly.
This will probably involve marking the if __name__ == "__main__" bit as noqa, as I don't thing we can measure coverage on those couple lines.


[BUG 🪲] about Video color

Describe the bug 🐛
The video after recording had an incorrect color problem. I tried other options in ColorFormat, but I couldn't solve it.

OS 🤖

Version: [window11]
Build[24H2 26100.2605]

My code
fn get_window(title:&str) -> Window {
        let window = Window::from_name(title).unwrap();
        println!("{:?}",window);
        window
    }
let capture_target = get_window("任务管理器");

let settings = Settings::new(
    // Item to capture
    capture_target,
    // Capture cursor settings
    cursor,
    // Draw border settings
    border,
    // The desired color format for the captured frame.
    ColorFormat::Rgba8,
    // Additional flags for the capture settings that will be passed to user defined `new` function.
    "Yea this works".to_string(),
);
let i=Capture::start_free_threaded(settings).expect("Screen capture failed");

This problem does not occur when recording full-screen

#35 same


account creation

pretend like this is a draft PR

This pull request has gone stale, since it predates the project name change. In addition, this will also need to be reworked for EntityFrameworkCore. All these things will need to be addressed before this can be merged.


docs: add missing convention link to CONTRIBUTING page

Compare: https://github.com/LN-Zap/zap-desktop/blob/master/CONTRIBUTING.md
With: https://github.com/Empact/zap-desktop/blob/docs/convention-link/CONTRIBUTING.md
Note I link to: https://conventionalcommits.org/
An alternative target is: https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional
I find them both pretty difficult to parse, so if you guys have another link in mind, lmk.

/cc @mrfelton

The angular convention has better documentation that is easier to parse:
https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines
But it is not 100% inline with the conventional standard.I'm not sure that there is any meaningful difference for our purposes though. I think they only differ on the conventions for the scope (the optional part in brackets that goes after the type)

Hmm. Then I guess going with https://conventionalcommits.org/ is a good option given it links to the angular docs as well as the other one. Sound good?

I think that is ok. It provides a good overview of the basics. I think the only other thing that is useful for people to know is what types are valid in addition to feat and fix - but I already included this information directly on the CONTRIBUTING.md doc for easy reference purposes.
Also, if you have the commit-msg git hook enabled and try to commit with an invalid type, it will list out all of the valid types in the error message.


PoorPocketsMcNewHold's contributions to block google

Hi @PoorPocketsMcNewHold ,
Maybe you already noticed; I'm the initial creator of https://github.com/nickspaargaren/pihole-google!
I'd like to thank you for your contributions to our repository. I am very happy with your effort and would like to send you some investment money in crypto valuta. You can choose, I'll try to convert some.
$50. Anything you like; bitcoin, ethereum, litecoin, whatever, you name it. BAT perhaps? https://brave.com/nic944 :)
Just send me the correct address and which valuta you'd like. Again, thank you.
Nick Spaargaren
(No this isn't a scam, not aware how crypto works? Just download brd.com and find out, I have send you an email so you can reply your address there)

Hi Nick, thanks hugely for this donation.
This actually happens at a time in which i've actually unlocked some free time (Well, Not exactly right NOW as i'm currently in vacation for a short couple of days), in which i want to dedicate myself more on the project i currently contribute on GitHub, especially this one due to the recent gain of attention that we've got recently.
I didn't had any current active crypto account at this time of writing, so i've followed your suggestion and created myself one at BRD.
I suggest Ethereum should do, but feel free to contact me more about it, at my address<EMAIL_ADDRESS>Other than that, Here's my ethereum address : 0x4C9A86c0b24303fEC712A58EAd5AD610fe0f18C6

https://etherscan.io/tx/0xaaa9a30cba630c7a3e4f4241d77cd45e0a3072d887fa714efc50d348247c4c99
Here you go! Again, thank you!

Pretty obvious with the ether proof, but i've indeed received it. I also return the compliment, for the donation, but also the creation of this liste that I use every days.


[v2] Adding Standard Resource metrics to KEDA

Signed-off-by: Chaitanya Kuduvalli Ramachandra<EMAIL_ADDRESS>
Provide a description of what has been changed
KEDA currently supports only external metrics. We wish to support standard HPA metrics like CPU and memory usage through KEDA. This pr is to enable the same.
Checklist

[X] A PR is opened to update the documentation on https://github.com/kedacore/keda-docs
[X] Commits are signed with Developer Certificate of Origin (DCO)
[X] Tests have been added

Fixes #852

KEDA Docs pr:
https://github.com/kedacore/keda-docs/pull/188

Please review the pr. However, please wait before this is merged.

With this change, our new spec looks like this:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: {scaled-object-name}
spec:
  scaleTargetRef:
    deploymentName: {deployment-name} # must be in the same namespace as the ScaledObject
    containerName: {container-name}  #Optional. Default: deployment.spec.template.spec.containers[0]
  pollingInterval: 30  # Optional. Default: 30 seconds
  cooldownPeriod:  300 # Optional. Default: 300 seconds
  minReplicaCount: 0   # Optional. Default: 0
  maxReplicaCount: 100 # Optional. Default: 100
  hpaConfig:           # Optional. If not set, KEDA won't scale based on resource utilization
    resourceMetrics:
      name: cpu/memory # Name of the resource to be targeted
      target:
        type: value/ utilization/ averagevalue
        value: 60 # Optional
        averageValue: 40 # Optional
        averageUtilization: 50 # Optional
    behavior:
  triggers:
  # {list of triggers to activate the deployment}

However, scaling on resource of the deployment feels like another trigger for me; not something we slap on the new scaled object spec or is this just me?
Reason why this feels odd to me is that ScaledObject relies on triggers, for example Service Bus queue, where we will almost never want to scale on CPU in the same scaled object but rather a new trigger in the list or another scaled object, no?

@tomkerkhove I had a discussion with @zroubalik before making this change and this is how we came up with a solution that we will support it as a standard resource metric than as a scaler. This is because HPA also has different types of metrics: Resource metrics and External metrics. Scalers support external metrics. So, we thought of using the resource metrics of HPA directly. Hence made this change. But looking forward to a discussion on this.

One of the strengths about KEDA is that people who are not a Kubernetes expert don't need to know how Kubernetes handles scaling.
I can see why we want to open up HPA configuration to those who have the expertise, but for scaling on resource metrics I would say that that's different and has to align with other scalers to be more consistent.
An example of a current one is this:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
  labels:
    app: order-processor
    deploymentName: order-processor
spec:
  scaleTargetRef:
    deploymentName: order-processor
  # minReplicaCount: 0 Change to define how many minimum replicas you want
  maxReplicaCount: 10
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders
      queueLength: '5'
    authenticationRef:
      name: trigger-auth-service-bus-orders

But if I were to only scale on CPU then it would look like this:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
  labels:
    app: order-processor
    deploymentName: order-processor
spec:
  scaleTargetRef:
    deploymentName: order-processor
  # minReplicaCount: 0 Change to define how many minimum replicas you want
  maxReplicaCount: 10
  hpaConfig:           # Optional. If not set, KEDA won't scale based on resource utilization
    resourceMetrics:
      name: cpu # Name of the resource to be targeted
      target:
        type: averagevalue
        averageValue: 40 # Optional
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders
      queueLength: '5'
    authenticationRef:
      name: trigger-auth-service-bus-orders

What if it looked like this:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
  labels:
    app: order-processor
    deploymentName: order-processor
spec:
  scaleTargetRef:
    deploymentName: order-processor
  # minReplicaCount: 0 Change to define how many minimum replicas you want
  maxReplicaCount: 10
  advanced:
    horizontalPodAutoscalerConfig:           # Optional. If not set, KEDA won't scale based on resource
      behavior:
  triggers:
  - type: resource-metrics
    metadata:
      metric: cpu
      value: 40
    authenticationRef:
      name: trigger-auth-service-bus-orders

This allows people to:

Autoscale based on resource-metrics and can simply be based on HPA default approach, but users don't have to worry about that
People can still influence the behavior of the HPA, but indicates that this is more of an advanced scenario and remove the abbreviation (HPA) for folks who are new to Kubernetes scaling.

PS: I'm not saying you didn't do a good job but just want to have this aligned because it deviates from the rest and we dare to assume everybody is a Kubernetes expert which is far from true.
Thoughts from you folks as well on this @zroubalik @ahmelsayed @jeffhollan?

I have seen some requests for this functionality among users and I like this idea, eventhough it is a corner case and won't be (likely) used that much.
Currently there's no way how can user modify the HPA that is being generated by KEDA, therefore there's no way how to setup scaling both on external trigger and cpu/memory resources.
And since we have already added behavior, I don't se a problem in adding other optional fields if we add a proper documentation for these features. Users not so familiar with kubernetes could easily ignore this setting.
@tomkerkhove  I am not saying that your proposed solution is bad, I can see your point behind putting the setting under the triggers sections, but from my POV the intention here is to provide a way for experienced users to modify the created HPA, not to provide KEDA scaling based on cpu/memory resources. So by putting this under HPA related config (next to behavior) we are trying to distiguish between scaling directly managed by KEDA (ie. triggers) and config (scaling) managed solely by HPA (CPU/memory) -> KEDA is not being involved in this kind of scaling at all.
This solution has small technical side-benefits, we don't have to care about validation of that
config as it is already covered by HPA and this is a direct part of HPA Spec -> no need for us to do any modification, if there are any changes in the original spec. And if there are other HPA related settings coming in the future, we can easily add them here and everything will be in one place.
If we introduce a separate scaler for this (as you have proposed), we will have to validate the fields, keep track of that Spec (I admit that it will likely not change in the future) and implement more things around scalers as this is a special kind of scaler which requires a special handling. These changes shouldn't be too complex and hard to implement, but I just wanted to bring this under the consideration as well.
BTW I'd prefer horizontalPodAutoscalerConfig over hpaConfig for the field name.

@zroubalik Have changed the field name to horizontalPodAutoscalerConfig

@zroubalik I can see what you're saying but that means you are forcing people to understand how Kubernetes uses HPA and they should know they need an HPA to scale based on CPU/Memory.
For me this is not a good approach as KEDA should be the autoscaling layer folks have to know, all the rest is technical detail. It would be more inline with scaling other workloads.
If I have an API & queue worker then I'd need to have this:
Queue Worker:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
  labels:
    app: order-processor
    deploymentName: order-processor
spec:
  scaleTargetRef:
    deploymentName: order-processor
  # minReplicaCount: 0 Change to define how many minimum replicas you want
  maxReplicaCount: 10
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders
      queueLength: '5'
    authenticationRef:
      name: trigger-auth-service-bus-orders

API:
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: order-api-scaler
  labels:
    app: order-api
    deploymentName: order-api
spec:
  scaleTargetRef:
    deploymentName: order-api
  # minReplicaCount: 0 Change to define how many minimum replicas you want
  maxReplicaCount: 10
  hpaConfig:           # Optional. If not set, KEDA won't scale based on resource utilization
    resourceMetrics:
      name: cpu # Name of the resource to be targeted
      target:
        type: averagevalue
        averageValue: 40 # Optional
  triggers:

This feels odd, no? One might say you can just use HPA directly but then you don't have a unified layer anymore.

For me; KEDA is really about making autoscaling deadsimple and use same approach, regardless of the source.

@tomkerkhove yeah, you have got some points. Let's discuss this on the call next week.

@ahmelsayed what do you think about this?

From my prospective, one of the main reasons for using HPA for 1->N scaling has always been being able to make use of all the default resources HPA supports for scaling there, along side the custom metrics provided by KEDA. Providing the right interface for that however was always a bit of an unknown. I didn't know what's the best way to allow that that will be both flexible enough to be useful, but doesn't leak a lot of underlying concepts and complicated the ScaledObject interface.
I think there is value in having a generic way for users to patch the HPA generated by KEDA if needed (even if just as an advanced scenario), while still retaining the option to add knobs on the ScaledObject later on for that as well.
When I thought about it before, I was thinking of a way to allow users to provide a merge patch for HPA per ScaledObject that KEDA could apply on the generated HPA as a final step as this would allow you to see what the object looks like, then define any transform/patch for it that you like.
In that case the example Tom shared above
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
spec:
  scaleTargetRef:
    deploymentName: order-processor
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders
      queueLength: '5'
    authenticationRef:
      name: trigger-auth-service-bus-orders
+  patches:
+    hpa: {}

or have it defined as a patch in another object with the same name, something like
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledPatch
metadata:
  name: order-processor-scaler
spec:
  hpaPatch: {}

However, it seemed a bit of an overkill at the time and I wasn't sure if we might find a better way in the future, so I punted on it.
The interface proposed by this PR seems to more or less match what I was thinking about above (albeit it only takes *autoscalingv2beta2.ResourceMetricSource and I think it should probably take a []*autoscalingv2beta2.ResourceMetricSource instead).
I understand @tomkerkhove concern about additional complexity, but I think if the option listed under an advanced section as a patch to the generated HPA and not something that's always in your face when learning about KEDA would meet that requirement half-way.

Hey, I'm glad I found this PR because this is exactly what I was trying to do. Hopefully there is a consensus soon. Is there a roadmap for when 2.0.0 will be stable enough for release?

We're actually trying to fix 2 things as far as I see:

Give people control to manipulate the HPA created by KEDA
Provide KEDA users to scale based on standard metrics.

I'm fully ok with opening up the HPA related changes as @ahmelsayed suggested or the current proposal but I would highly recommend to move the CPU/memory scaler to triggers since that's aligned with another approach.
Let's discuss during the standup tomorrow maybe?

Let's discuss during the standup tomorrow maybe?

+1

@ckuduvalli we disscussed this on the call and for now we will go with direction proposed in this PR. We can add a separate resource based scalers later, if there's a need from community.
Could you please update you PR:

to put the whole config under advanced as proposed by @tomkerkhove here: https://github.com/kedacore/keda/pull/874#issuecomment-642431089)
to use []*autoscalingv2beta2.ResourceMetricSource instead as proposed by @ahmelsayed here https://github.com/kedacore/keda/pull/874#issuecomment-648332340

@tomkerkhove @ahmelsayed am I correct? 😄

Certainly!
This is what we've discussed during standup yesterday:

Standard Resource metrics is more of an advanced scenario where people want to manipulate the HPA that is being created

Tom has the feeling that we should align it with other triggers to provide a consistent approach for users and carve out the mutation of the HPA
This brings a lot of additional complexity so it's not sure if it's worth it
We will start with the advanced scenario and see if people start asking for a CPU/Memory trigger

sorry I couldn't attend the standup yesterday. @zroubalik @tomkerkhove will update the pr as per the comments

No worries!

@tomkerkhove @ahmelsayed @zroubalik Have updated this pr as well as the docs pr. Please check

@ahmelsayed ok to merge?


kontrol show to allow full path of contract

This PR addresses issue https://github.com/runtimeverification/kontrol/issues/620 and will close it once this is merged.
This PR introduces changes that allow the full path of the contract with the test name, e.g., test%version1%test_address to be passed as an input. Previously, it will only match the contract name and the path directory, e.g., test% will not be matched.
I am not sure how to add an integration test for this but I have tested it locally as shown below:

I have created a foundry project min_test_example/ with 3 identical contracts, MinExampleTest as seen below:

with each of the contract contains the same test:

I ran the following commands in the modified kontrol/ directory to prove all 3 versions of the same test:
poetry install
poetry run kontrol clean --foundry-project-root ../min_test_example/
poetry run kontrol build --foundry-project-root ../min_test_example/
poetry run kontrol prove --foundry-project-root ../min_test_example/

I ran the following kontrol show command to make sure that it will fail as there are multiple files with the same test:
poetry run kontrol show MinExampleTest.test_sample --foundry-project-root ../min_test_example/

Output:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/jinxinglim/Codes/RV/kontrol/src/kontrol/__main__.py", line 125, in main
    execute(options)
  File "/home/jinxinglim/Codes/RV/kontrol/src/kontrol/__main__.py", line 257, in exec_show
    output = foundry_show(
  File "/home/jinxinglim/Codes/RV/kontrol/src/kontrol/foundry.py", line 659, in foundry_show
    contract_name, _ = single(foundry.matching_tests([options.test])).split('.')
  File "/home/jinxinglim/.cache/pypoetry/virtualenvs/kontrol-5yuoxZea-py3.10/lib/python3.10/site-packages/pyk/utils.py", line 298, in single
    raise ValueError('Expected a single element, found more', fst, snd)
ValueError: ('Expected a single element, found more', 'test%MinExampleTest.test_sample()', 'test%version4%MinExampleTest.test_sample()')

I ran the following kontrol show commands one at a time to make sure that it can take in the full path as its input and search for it:
poetry run kontrol show test%MinExampleTest.test_sample --foundry-project-root ../min_test_example/
poetry run kontrol show test%version3%MinExampleTest.test_sample --foundry-project-root ../min_test_example/
poetry run kontrol show test%version4%MinExampleTest.test_sample --foundry-project-root ../min_test_example/

Questions

Do you think we should add any integration test to ensure that this command works for subsequent PRs? If yes, can someone guide me on how I can do it?

Do you think the ValueError output is okay to be displayed if the command failed due to multiple files with the same test?

The key functionality update looks great to me, but could you please also look at improving the error message, as you've mentioned? We can print the same message as we're showing for kontrol view-kcfg in this case, e.g.:
ValueError: Found 3 matching proofs for ERC20.totalSupply:None. Provide a full signature of the test, e.g., 'ERC20.totalSupply()' --version None. Error: ('Expected a single element, found more', 'test%ERC20.totalSupply()', 'lib%forge-std%src%interfaces%IERC20.totalSupply()')

Hi @palinatolmach. I have pushed the change to display the same error message as kontrol view-kcfg in commit https://github.com/runtimeverification/kontrol/pull/692/commits/1e800b05d369620d65a0b9cb8a699ec4f49678a5.


[video_player]: added test class to fix video_player unit tests

Description
In order for https://github.com/flutter/plugins/pull/2544 to land; extra testing classes need to be made available.
Related Issues
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

@cyanglaz please review this PR after landing.
I'm landing on red in order to fix the tree, all CI failures are a result of failures not in this package but with something that depends on it that can't be fixed until this landed.


[FR] Add ability to tip markets and free response answers

In addition to comments, it'd be nice if you could tip markets (e.g. for creating an interesting market) and free response answers (e.g. for creating a good or humorous answer)

https://github.com/manifoldmarkets/manifold/pull/798 kiinda addresses this
I do want to add market tips for real at some point

market tips are in!


[Event Request] Codeunit 230 GenJnlManagement - procedure GetJournalSimplePageModePreference - OnBeforeGetJournalSimplePageModePreference

Please add an Event OnBeforeGetJournalSimplePageModePreference in GetJournalSimplePageModePreference in Codeunit 230 GenJnlManagement
There was already a similar ticket: https://github.com/microsoft/ALAppExtensions/issues/3783
But this has not been implemented.
GetJournalSimplePageModePreference(PageIdToCheck: Integer): Boolean
    var
        JournalUserPreferences: Record "Journal User Preferences";
    begin
        // Get journal page mode preference for a page; By defaults this returns FALSE unless a preference
        // is set

        OnBeforeGetJournalSimplePageModePreference(PageIdToCheck); <-- NEW EVENT

        JournalUserPreferences.Reset();
        JournalUserPreferences.SetFilter("User ID", '%1', UserSecurityId);
        JournalUserPreferences.SetFilter("Page ID", '%1', PageIdToCheck);
        if JournalUserPreferences.FindFirst() then
            exit(JournalUserPreferences."Is Simple View");
        exit(false);
    end;

    [IntegrationEvent(false, false)]
    local procedure OnBeforeGetJournalSimplePageModePreference(PageIdToCheck: Integer)
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: .


Fix Uninstaller

Description
This pr fixes an issue that prevents the Liqo full uninstallation
How Has This Been Tested?

[x] Locally on KinD

/merge


User count limit to 50(?)

Is your feature request related to a problem? Please describe.
I experience, that the 51st user who registers on the system is not visible in the admin user list and therefore can't be activated
Describe the solution you'd like
I'm not 100% sure, but after a quick search in the code, it seems that the user count is limited to 50 users
(apps/web/routers/users.py)
Describe alternatives you've considered
I wonder if or why that limit is required. Might be nice to make the value configurable and not hard-coded if possible
Would be great if you could help here.
Keep up the great work!

Hi, Thanks for reporting this issue, I'll take a look in a bit.

Thank you very much for the quick reply and fix!
I'll test asap (possibly not before next week) and report back.

Hi there,
I can confirm the fix works as expected. Thank you very much! :)


Set default memory and storage to use for the driver job if no config…

… values are provided.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 26.53%. Comparing base (2308ff5) to head (3e2615f).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1062   +/-   ##
=======================================
  Coverage   26.53%   26.53%
=======================================
  Files           9        9
  Lines        1715     1715
=======================================
  Hits          455      455
  Misses       1260     1260

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


bundle clean force error

[X] I'm on Docker

[X] I understand Docker may be unsupported

Description
Since the update to v4 a few days ago (April 23rd?) we encountered a similar error to https://github.com/envygeeks/jekyll-docker/issues/268.
After making including the chown change in our pipeline we are now encountering an issue
Cleaning all the gems on your system is dangerous! If you're sure you want to remove every system gem not in this bundle, run `bundle clean --force`.

We are running the following commands
rm -fr $JEKYLL_VAR_DIR/*
chown jekyll:jekyll -R /usr/gem
jekyll build -d $JEKYLL_VAR_DIR

Output
Bundle complete! 4 Gemfile dependencies, 31 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Cleaning all the gems on your system is dangerous! If you're sure you want to remove every system gem not in this bundle, run `bundle clean --force`.

Expected
Bundle complete! 4 Gemfile dependencies, 31 gems now installed.
Bundled gems are installed into `/usr/local/bundle`
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-musl]
Configuration file: /tmp/build/bfc0b666/git/_config.yml
            Source: /tmp/build/bfc0b666/git
       Destination: /var/jekyll
 Incremental build: disabled. Enable with --incremental
      Generating...
       Jekyll Feed: Generating feed for posts
                    done in 5.446 seconds.
 Auto-regeneration: disabled. Use --watch to enable.

It looks like #268 and #269 are both related to this issue. I had a similar experience, build which was on FROM jekyll/jekyll:4.0 stopped working, it was the bundle install operation that failed, and the appearance is that while jekyll 4.0.0 was released some time ago, the jekyll/jekyll:4.0.0 image itself is not immutable and has changed.
I went looking for a tag that might refer to that previous version of 4.0.0 and came up empty. It was not possible for me to change the FROM in my own Dockerfile to make the build succeed again, without referring back to jekyll/jekyll:3.8.6 which is less than ideal. Worse, I wasn't able to figure out exactly how the build machinery produces this image to roll back the recent commits and try rebuilding it for myself.
As commenters in the related thread have already stated, tags (at least some tags) should be immutable, it is very bad for breaking changes to erase historical images that worked, rendering derivative Dockerfiles unusable. I noticed an appeal for funding when I was in there looking at those commits I wanted to roll back. I understand open source is on a volunteer basis and hope you will not take these comments the wrong way, maintainers.
My intention is to make the project better for everyone, the easiest way to solve this issue going forward IMHO is to add a tag at build/push time which includes the commit sha, so that older images can be referenced and inspected for differences rather than overwriting them when a new image is built. It would be nice to honor semver, but this will make progress within the docker build harder to achieve, when the image tag used is meant to reflect the version of Jekyll included from upstream. I see how this could make it difficult to do versioning effectively.
There are still things you can do that make sure downstream pipelines won't break with new builds, like guaranteeing every image pushed will get a unique tag, and historical tags will only be removed in extreme cases, not casually overwritten and discarded whenever a new build is undertaken. But that horse has left the barn, so as for understanding what changed in the build and how to restore compatibility in the 4.0.0 line, while preserving the Dockerfile author's intended updates, I haven't done enough digging to understand what should happen next.

This issue has been fixed.  Technically we still bundle clean, or try to, we just ignore the error and hide it because we don't care if it succeeds, we just wanna try on your behalf.

This issue has been fixed. Technically we still bundle clean, or try to, we just ignore the error and hide it because we don't care if it succeeds, we just wanna try on your behalf.

Has this fix been rolled out into production or am I doing something wrong such that the applied fix is not working for me?
I have a Dockerfile that begins FROM jekyll/builder, which was working fine until today when I noticed that the jekyll/builder:latest image now includes Bundler 2.1.4 by default. My project's Gemfile was bundled with 1.17.3 so I amended my own container's entry point to run gem install -v 1.17.3 bundler before calling this project's.
Unfortuantely, this caused a permissions error I hadn't encountered before which I believe is the same as what is described #272. In my case, setting JEKYLL_ROOTLESS=true fixes the issue (blunt but effective…), which is when I ran into the bundle clean error described in this thread.
Now I'm in a catch-22, because if I work around the permission issues by running jekyll as UID and GID 0, then line 29 in repos/jekyll/copy/all/usr/jekyll/bin/bundle is executed (due to the earlier check on line 12 correctly recognizing that we are running as root and thus not "skipping out" before the bundle clean command is called), or else if I don't run as root to avoid the bundle clean error, I hit the earlier permissions problem.
I can't immediately see where in the bundle wrapper script errors from clean are "ignored" either, so I feel like I must be missing something since you say this is already "fixed"?
Any help would be appreciated as I try to restore our CI/CD systems as soon as possible.

The problem is you are setting the Jekyll user to UID/GID = 0 and then it's chowning the folder to UID/GID 0 thus killing your permissions, don't change Jekyll's UID/GID, let the image set it when it runs if you need a different one via the environment variables provided to do so.

The problem is you are setting the Jekyll user to UID/GID = 0 and then it's chowning the folder to UID/GID 0 thus killing your permissions, don't change Jekyll's UID/GID, let the image set it when it runs if you need a different one via the environment variables provided to do so.

Thanks for the quick reply! And I'm sorry, but I'm not sure I understand your answer. Maybe I was unclear, let me try to explain my situation again.
I have a Dockerfile that is based on jekyll/builder. This Dockerfile uses its own entry point script. At some point in my own entry point script, I have this:
    # Execute the original image's own entrypoint.
    /usr/jekyll/bin/entrypoint jekyll build -d "$JEKYLL_DATA_DIR" "$INPUT_JEKYLL_BUILD_OPTS"

The idea here is that I thought it would be possible to simply call up to the official Jekyll Builder entry point, and this did work for quite a while, until today.
My own entry point script needs to run as root, but no where do I change the values for JEKYLL_UID or JEKYLL_GID, which means that the upstream's default of 1000 is applied on each run, as to be expected. Nevertheless, I receive the following permissions errors in my build logs:
Errno::EACCES: Permission denied @ rb_file_s_rename -
(/home/jekyll/.gem/ruby/2.7.0/cache/i18n-0.9.5.gem,
/usr/gem/cache/i18n-0.9.5.gem)

If I'm not mistaken, this is the same permissions issue as described in the issue I linked earlier. Notice, importantly, that this permissions error occurs when JEKYLL_UID=1000; that's one reason I'm confused.
My understanding of your reply is that I should ensure that the jekyll user's UID and GID are not 0, i.e., that I allow the upstream /usr/jekyll/bin/entrypoint script to execute as root but then to change the Jekyll user's UID as appropriate. As far as I can tell, that is exactly the case already, yet the permissions errors are preventing successful builds. Note also that when I explicitly set the JEKYLL_UID and the JEKYLL_GID environment variables equal to 1000, the same permission error results.
One question I have is: Can you tell me what you are referring to when you say that "it is changing the folder to UID/GID 0"? What is the "it" in that sentence referring to?
So, since I am already not setting the Jekyll user or group ID to zero, and yet I'm still facing permissions issues in the default configuration, I am unsure what I might be doing wrong that prevents my builds from succeeding. When I attempt to solve the permissions error by explicitly setting JEKYLL_UID=1000, for example, the bundle clean error arises for the reasons I described earlier, leaving me in a catch-22 situation that cannot be resolved one way or the other.
Is there a third option?

So I took another stab at this this evening and I'm fairly certain that unless I'm just totally misusing the container, there's a problem that causes the build to fail with the bundle clean error here.
Some of the permissions I was having turned out to be a caching issue where my GitHub Actions runners were not pulling down the correct image. After resolving that by pinning my base container image with a digest as described here, I'm no longer seeing any permissions errors but once again hitting this bundle clean error.
The error is certainly caused by the fact that when I execute the entrypoint script, the following sequence of events occurs:

root calls the entrypoint script with these parameters: jekyll build -d /srv/jekyll --future

JEKYLL_UID and JEKYLL_GID are set to their default value of 1000 so no modifications are made.
The last line of the script exec "$@", and so…

…we next run /usr/jekyll/bin/jekyll build -d /srv/jekyll --future.

The code proceeds to line 26, which checks for the presence of a Gemfile and whether or not we're connected to the Internet.
Since both of these are true (I have a Gemfile and am connected to the Internet), the script next runs…

bundle install. So now we begin the /usr/jekyll/bin/bundle script, which wraps bundle.

On line 4 is where the default-gem-permissions call is made. This is the line that was missing when I posted my earlier comment. That's part of why the permissions errors may have been cropping up. Now that default-gem-permissions is being called, the permissions errors are gone.
However, unfortunately, if you examine the call strack, we have not yet ever run su-exec jekyll, which means we are still executing the script as root. This means that the check on line line 12 fails (because remember, there is a Gemfile present so the first test returns a falsey value, and we are still executing with ID 0, so the second test [ "$(id -u)" != "0" ] also returns a falsey value).

Finally, since this script was invoked as bundle install, the test on line 16 returns a truthy value, and we immediately continue to line 18 where we run su-exec jekyll $exe check, which expands to su-exec jekyll /usr/local/bin/bundle check.

Since this is the very first run of the script, we have not yet had a chance to install any dependencies described in the Gemfile. As a result, bundle check returns a 1, which is negated by the script, giving us a truthy value and forcing us into the bundle clean code branch.

I can not see any way around this sequence of events that works in all cases and avoids the bundle clean error, so I'm really curious to learn about how this issue was fixed.
As usual, thanks so much for your help.

I'll see if I can replicate it and take a look today or tomorrow!

I'll see if I can replicate it and take a look today or tomorrow!

Many thanks for looking into this for us all. Please let me know if there is any more information you need that you think I can provide and I will do my best to get it to you.

I arrived here because of the same issue when building a Docker image from https://github.com/cobbler/cobbler.github.io/blob/master/Dockerfile
Replacing the first line to FROM jekyll/jekyll:3 as build got me going.


[BUG] - Provisioning Failed/Unauthorized IP addres

Describe the bug
The pvc remains pending after deployment. Logs showing 401 error when I run kubectl logs csi-vultr-controller-0 -n kube-system

To Reproduce
Steps to reproduce the behavior:

Deploy VKE cluster
kubectl apply -f https://raw.githubusercontent.com/vultr/vultr-csi/master/docs/releases/latest.yml
Deploy pvc

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: vultr-block-storage

Expected behavior
No error, pvc deployed and running.
Desktop (please complete the following information where applicable:

OS: Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-43-generic x86_64)
Kubectl: Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.3", GitCommit:"434bfd82814af038ad94d62ebe59b133fcb50506", GitTreeState:"clean", BuildDate:"2022-10-12T10:57:26Z", GoVersion:"go1.19.2", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.4", GitCommit:"95ee5ab382d64cfe6c28967f36b53970b8374491", GitTreeState:"clean", BuildDate:"2022-08-17T18:47:37Z", GoVersion:"go1.18.5", Compiler:"gc", Platform:"linux/amd64"}

Add any other context about the problem here.

--allow-privileged must be enabled for the API server and kubelet
from the vultr-csi requirements

@ddymko
How can I set this when I don't have access to the VKE control plane?

Solved:
For future reference for anyone facing same errors:
vultr-csi are automatically deployed along with VKE.
vultr-csi secret are also automatically deployed following the example on vultr-csi git repo will lead to authentication error.
You don't need to do most of the stuffs on this tutorial page if you're using VKE
Also check that vultr-block-storage is available in your location else it will throw an error {"error":"Unable to add block storage: Unable to find a block storage cluster in that location.","status":400}


user12986714: Watch prudvihub.blogspot

user12986714 requests the watch of the watch_keyword prudvihub\.blogspot. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

prudvihub\.blogspot has been seen in 0 true positives, 0 false positives, and 0 NAAs.

It appeared in this NATO on Salesforce.SE. Affiliation was undisclosed and the blog post linked really relevant to the question (some keywords overlap, but it seems to be largely superficial)

Approved by NobodyNada in Charcoal HQ


chore: conventional order for configmap

Not really an important pull request, just to be convenient

Wait, i've made an error. I wanted to propose to you a single update, commit dcc19d2a206f3e52a5b696e864d07611da0ae833.
This is imo an unopiniated change that would just slightly increase hapiness of developers to get the same structure everywhere.
But in the mean time, i've made other commits on my main branch that do not intend to join your repo :

code format, it will make other developers fork unhappy because of conflicts
opiniated changes in csharp (xunit & where to put cursor)

I'll make a second PR in few hours when I'll be available to correct it. Sorry

I am closing this one as I created the real fix in https://github.com/rafamadriz/friendly-snippets/pull/251


[BUG] : Hydration Error Issue When Running npm run dev

Description
Today, while attempting to set up the project locally, I successfully installed all the necessary packages and configured the development environment. However, when I executed the npm run dev command on port 3000, I encountered a hydration error issue. I made an effort to debug this issue, but unfortunately, I was unable to identify the root cause.
Screenshots

Do you want to work on this issue?
None
Additional information
No response

Thank you for raising. Can you come and chat to us in EddieHub Discord so we can debug, then we can raise an issue as this is likely to be a local issue http://discord.eddiehub.org

okay! thanks @eddiejaoude . Will chat on discord


Best place to ask questions + getting data points?

What is the best place to ask general questions about this plugin? I don't want to clutter up the issue box, but I haven't found a good alternative space to ask questions.
(My actual question: ) I've been using the plugin to get my steps for a whole day, but I would like to get the actual step data points to produce my own graph. Currently, I'm using something like this:
window.plugins.healthkit.sumQuantityType({
  'startDate': startDate,
  'endDate': endDate,
  'sampleType': 'HKQuantityTypeIdentifierStepCount'
}

My startDate and endDate are defined by moment.  This utilizes sumQuantityType, so it only return the sum. How can I get the individual points?
I've been following this tutorial: http://kingsfleet.blogspot.co.uk/2015/02/how-long-did-i-sleep-last-night-using.html

querySampleType does what I want! (for the second part of my question - still curious about the first part!). Also, would it be useful to contribute pull request documentation to  README.md?

Thx for the PR :+1:


Can't inject into Application class

I am trying to inject a WorkManagerFactory into my Application class, I get the following error for the dependencies needed
[Dagger/MissingBinding] retrofit2.Retrofit.Builder cannot be provided without an @Inject constructor or an @Provides-annotated method.

The app builds successfully when I just remove the field in the Application class but I need it to inject dependencies into my WorkManager
Application class
@HiltAndroidApp
class App : Application(), Configuration.Provider {

    @Inject
    lateinit var refreshTokenSchedulerFactory: RefreshTokenSchedulerFactory

    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance().sendUnsentReports()
    }

    override fun getWorkManagerConfiguration(): Configuration =
            Configuration.Builder()
                    .setMinimumLoggingLevel(android.util.Log.DEBUG)
                    .setWorkerFactory(refreshTokenSchedulerFactory)
                    .build()
}

Work Manager factory
class RefreshTokenSchedulerFactory @Inject constructor(
        val preferencesHelper: PreferencesHelper,
        val dataManagerAuth: DataManagerAuth
) : WorkerFactory() {

    override fun createWorker(appContext: Context, workerClassName: String, workerParameters: WorkerParameters): ListenableWorker? =
            RefreshTokenScheduler(appContext, workerParameters, preferencesHelper, dataManagerAuth)
}

NetworkModule
@Module
@InstallIn(ActivityComponent::class)
object NetworkModule {

    @Provides
    fun provideBaseOkHttpClient(
            ikorInterceptor: IkorInterceptor,
            httpLoggingInterceptor: HttpLoggingInterceptor,
            connectivityInterceptor: ConnectivityInterceptor,
            receivedCookiesInterceptor: ReceivedCookiesInterceptor,
            sslSocketFactory: SSLSocketFactory,
            trustManager: TrustManager
    ): OkHttpClient = OkHttpClient.Builder()
            .sslSocketFactory(sslSocketFactory, trustManager as X509TrustManager)
            .hostnameVerifier(HostnameVerifier { _, _ -> true })
            .connectTimeout(60, TimeUnit.SECONDS)
            .readTimeout(60, TimeUnit.SECONDS)
            .addInterceptor(httpLoggingInterceptor)
            .addInterceptor(connectivityInterceptor)
            .addInterceptor(ikorInterceptor)
            .addInterceptor(receivedCookiesInterceptor)
            .build()

    @Provides
    fun provideHttpLoggingInterceptor(): HttpLoggingInterceptor = HttpLoggingInterceptor()
            .setLevel(HttpLoggingInterceptor.Level.BODY)

    @Provides
    fun provideIkorInterceptor(preferencesHelper: PreferencesHelper): IkorInterceptor = IkorInterceptor(preferencesHelper)

    @Provides
    fun provideConnectivityInterceptor(@ApplicationContext context: Context): ConnectivityInterceptor = ConnectivityInterceptor(context)

    @Provides
    fun provideReceivedCookiesInterceptor(preferencesHelper: PreferencesHelper): ReceivedCookiesInterceptor = ReceivedCookiesInterceptor(preferencesHelper)

    @Provides
    fun provideRetrofitBuilder(): Retrofit.Builder = Retrofit.Builder()
            .baseUrl(BaseUrl.defaultBaseUrl)
            .addConverterFactory(NullOnEmptyConverterFactory())
            .addConverterFactory(ScalarsConverterFactory.create())
            .addConverterFactory(GsonConverterFactory.create())
            .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
}

BaseApiManager
class BaseApiManager @Inject constructor(
        retrofitBuilder: Retrofit.Builder,
        baseOkHttpClient: OkHttpClient
) {
...
}

DataManagerModule
@Module
@InstallIn(ActivityComponent::class)
object DataManagerModule {

    @Provides
    fun provideDataManagerAuth(
            baseApiManager: BaseApiManager
    ): DataManagerAuth = DataManagerAuth(baseApiManager)
    ...
}

DataManagerAuth
@Singleton
class DataManagerAuth @Inject constructor(
        private val baseApiManager: BaseApiManager
) {
...
}

Hi! Have you removed the default initialiser from the AndroidManifest.xml file? The Hilt docs mention it.
See this other link to the WorkManager docs to do that.

Also, your modules are installed in the ActivityComponent instead of the ApplicationComponent or SingletonComponent. If you're trying to inject that info in an Application, those bindings should be available there

Thanks a lot, I made the module to be installed in ApplicationComponent, and have started using hilt's work manager provider.


Remove OVM3 sourcecode from cosmic-core

Tested in the following way:

Build source
Created RPMs
Installed RMPs
Cleaned DB
Deployed DC
Deployed VM

LGTM :+1:


APIs failing after connecteddrive backend update

Describe the issue
The status endpoints are not working.
I know that a new update to their server backend was pushed today.
DEBUG:urllib3.connectionpool:https://cocoapi.bmwgroup.com:443 "GET /eadrax-vcs/v1/vehicles?apptimezone=60.0&appDateTime=1652892002377&tireGuardMode=ENABLED HTTP/1.1" 500 111
ERROR:bimmer_connected.account:MyBMW API error '500 Server Error: Internal Server Error for url: https://cocoapi.bmwgroup.com/eadrax-vcs/v1/vehicles?apptimezone=60.0&appDateTime=1652892002377&tireGuardMode=ENABLED': { "statusCode": 500, "message": "Internal server error", "activityId": "10ad07a2-9688-4bb6-9b64-6a5da7f3c0cd" }
Traceback (most recent call last):
File "/opt/homebrew/bin/bimmerconnected", line 8, in
sys.exit(main())
File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/cli.py", line 282, in main
args.func(args)
File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/cli.py", line 101, in get_status
account = ConnectedDriveAccount(args.username, args.password, get_region_from_name(args.region))
File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 88, in init
self._get_vehicles()
File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 386, in _get_vehicles
response = self.send_request(
File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 313, in send_request
raise ex
File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 306, in send_request
response.raise_for_status()
File "/opt/homebrew/lib/python3.9/site-packages/requests/models.py", line 960, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: https://cocoapi.bmwgroup.com/eadrax-vcs/v1/vehicles?apptimezone=60.0&appDateTime=1652892002377&tireGuardMode=ENABLED
Expected behavior
It should bring back car data
Which Home Assistant version are you using?
not
What was the last working version of Home Assistant Core?
No response
What is your region?
Rest of world
MyBMW website

[X] I can still successfully login to the BMW MyBMW website and the car status is available there.
[X] I have MyBMW enabled for my vehicle.

Number of cars

[ ] I have 2 or more cars linked to the MyBMW account.
[ ] I have a Mini vehicle linked to my account.

Output of bimmer_connected fingerprint
No response
Anything in the logs that might be useful for us?
$ bimmerconnected status CREDS
DEBUG:bimmer_connected.account:Getting vehicle list
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): cocoapi.bmwgroup.com:443
eDEBUG:urllib3.connectionpool:https://cocoapi.bmwgroup.com:443 "GET /eadrax-ucs/v1/presentation/oauth/config HTTP/1.1" 200 580
DEBUG:bimmer_connected.account:Authenticating against GCDM with MyBMW flow.
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): customer.bmwgroup.com:443
DEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/authenticate HTTP/1.1" 200 411
DEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/authenticate HTTP/1.1" 302 0
eDEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/token HTTP/1.1" 200 1962
DEBUG:bimmer_connected.account:got new token HIDDEN with expiration date 2022-05-18 17:39:51.283206
DEBUG:bimmer_connected.account:Request to: https://cocoapi.bmwgroup.com/eadrax-vcs/v1/vehicles
DEBUG:bimmer_connected.account:Old token is still valid. Not getting a new one.
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): cocoapi.bmwgroup.com:443
DEBUG:urllib3.connectionpool:https://cocoapi.bmwgroup.com:443 "GET /eadrax-vcs/v1/vehicles?apptimezone=60.0&appDateTime=1652892002377&tireGuardMode=ENABLED HTTP/1.1" 500 111
ERROR:bimmer_connected.account:MyBMW API error '500 Server Error: Internal Server Error for url: https://cocoapi.bmwgroup.com/eadrax-vcs/v1/vehicles?apptimezone=60.0&appDateTime=1652892002377&tireGuardMode=ENABLED': { "statusCode": 500, "message": "Internal server error", "activityId": "10ad07a2-9688-4bb6-9b64-6a5da7f3c0cd" }
Traceback (most recent call last):
  File "/opt/homebrew/bin/bimmerconnected", line 8, in <module>
    sys.exit(main())
  File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/cli.py", line 282, in main
    args.func(args)
  File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/cli.py", line 101, in get_status
    account = ConnectedDriveAccount(args.username, args.password, get_region_from_name(args.region))
  File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 88, in __init__
    self._get_vehicles()
  File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 386, in _get_vehicles
    response = self.send_request(
  File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 313, in send_request
    raise ex
  File "/opt/homebrew/lib/python3.9/site-packages/bimmer_connected/account.py", line 306, in send_request
    response.raise_for_status()
  File "/opt/homebrew/lib/python3.9/site-packages/requests/models.py", line 960, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: https://cocoapi.bmwgroup.com/eadrax-vcs/v1/vehicles?apptimezone=60.0&appDateTime=1652892002377&tireGuardMode=ENABLED

Additional information
No response

Does it work for you again? I had lots of issues in my HA log, but also my private internet connection was broken for almost a week.

It's gone wrong for me too. BMW i3 rest-of-world.  Both bimmerconnected cli and HA fail similarly.
The main error seems to be http return 429 but it's then followed by too many retries error 401.  I don't think my error message adds anything to info from original poster.
DEBUG:bimmer_connected.account:Getting vehicle list
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): cocoapi.bmwgroup.com:443
DEBUG:urllib3.connectionpool:https://cocoapi.bmwgroup.com:443 "GET /eadrax-ucs/v1/presentation/oauth/config HTTP/1.1" 429 84
DEBUG:urllib3.util.retry:Incremented Retry for (url='/eadrax-ucs/v1/presentation/oauth/config'): Retry(total=2, connect=3, read=3, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Retry: /eadrax-ucs/v1/presentation/oauth/config
DEBUG:urllib3.connectionpool:https://cocoapi.bmwgroup.com:443 "GET /eadrax-ucs/v1/presentation/oauth/config HTTP/1.1" 429 83
DEBUG:urllib3.util.retry:Incremented Retry for (url='/eadrax-ucs/v1/presentation/oauth/config'): Retry(total=1, connect=3, read=3, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Retry: /eadrax-ucs/v1/presentation/oauth/config
DEBUG:urllib3.connectionpool:https://cocoapi.bmwgroup.com:443 "GET /eadrax-ucs/v1/presentation/oauth/config HTTP/1.1" 200 580
DEBUG:bimmer_connected.account:Authenticating against GCDM with MyBMW flow.
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): customer.bmwgroup.com:443
DEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/authenticate HTTP/1.1" 401 190
DEBUG:urllib3.util.retry:Incremented Retry for (url='/gcdm/oauth/authenticate'): Retry(total=2, connect=3, read=3, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Retry: /gcdm/oauth/authenticate
DEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/authenticate HTTP/1.1" 401 190
DEBUG:urllib3.util.retry:Incremented Retry for (url='/gcdm/oauth/authenticate'): Retry(total=1, connect=3, read=3, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Retry: /gcdm/oauth/authenticate
DEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/authenticate HTTP/1.1" 401 190
DEBUG:urllib3.util.retry:Incremented Retry for (url='/gcdm/oauth/authenticate'): Retry(total=0, connect=3, read=3, redirect=None, status=None)
DEBUG:urllib3.connectionpool:Retry: /gcdm/oauth/authenticate
DEBUG:urllib3.connectionpool:https://customer.bmwgroup.com:443 "POST /gcdm/oauth/authenticate HTTP/1.1" 401 190
ERROR:bimmer_connected.account:HTTPSConnectionPool(host='customer.bmwgroup.com', port=443): Max retries exceeded with url: /gcdm/oauth/authenticate (Caused by ResponseError('too many 401 error responses'))
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/requests/adapters.py", line 440, in send
    resp = conn.urlopen(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 876, in urlopen
    return self.urlopen(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 876, in urlopen
    return self.urlopen(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 876, in urlopen
    return self.urlopen(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 866, in urlopen
    retries = retries.increment(method, url, response=response, _pool=self)
  File "/usr/lib/python3.10/site-packages/urllib3/util/retry.py", line 592, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='customer.bmwgroup.com', port=443): Max retries exceeded with url: /gcdm/oauth/authenticate (Caused by ResponseError('too many 401 error responses'))
``

If you are using the custom component, please update to the latest version which includes some major rework in terms of how authentication (and authentication issues) are handled.
Cannot say much about the 500 Internal Server Error, except that there is apparently a new /eadrax-vcs/v2/vehicles API and you then have to get the state of each vehicle separately (using /eadrax-vcs/v2/vehicles/{VIN}/state. However this is currently not implemented by the library.

Sometimes it works, sometimes it doesn't.  It was working yesterday afternoon. This is in HA log now:
Logger: bimmer_connected.account
Source: /usr/local/lib/python3.9/site-packages/bimmer_connected/account.py:312
First occurred: 1:33:15 PM (1 occurrences)
Last logged: 1:33:15 PM

MyBMW API error '500 Server Error: Internal Server Error
etc

And 15 mins later 13:45, it's working again :-)
That's with latest sw (calls itself 0.8.12).
What's causing the rapid retries that the server is objecting to?
Max retries exceeded with url: /gcdm/oauth/authenticate (Caused by ResponseError('too many 401 error responses'))

Is that something bimmer is doing (and could be stopped from doing)?

Not sure why the API is so flaky at the moment - sometimes it also doesn't work if you're trying to do a fresh login (using username + password) from the app.
In our beta versions for 0.9.0 the authentication has been rewritten to not login with username/password but with an refresh_token provided by the API (same as the app doesn, username/password is only required on first login).
Unfortunately, you cannot just install the latest version to your current HA instance, it would break the component.
You can use the custom component until https://github.com/home-assistant/core/pull/71827 is merged (not sure if it will make it into 2022.6 or we have to wait for 2022.7).

Oh well, custom component works OK (once I'd realised that the battery level sensor had changed name and I spelt "battery" with a 'y'.  :-D ).  Thanks
Incidentally custom component has the advantage that it uses the python version that HA is using. I use HA  docker container which runs python 3.9 whereas my system runs python 3.10.

If using the integrated component, you should be using 3.9 as well?
Python 3.10 should be fine, Python 3.6 might create some issues in the future. Nevertheless, at least all of our tests are executed against Python 3.6 to 3.10 (e.g. https://github.com/bimmerconnected/bimmer_connected/actions/runs/2366016581).

Closing this as the problem should be solved with the latest custom component. The changes there will be included in the HA 2022.6 release, so it's possible to revert back once released.


WIP Fair preemptions in a cohort, rule S2-a

What type of PR is this?
/kind feature
What this PR does / why we need it:
This is an implementation of rule S2-a of https://sigs.k8s.io/kueue/keps/1714-fair-sharing#choosing-workloads-from-clusterqueues-for-preemption
In simple terms:
Preempt if the CQ of the incoming workload doesn't obtain a share higher than the final share of the CQ being preempted.
Which issue(s) this PR fixes:

Part of #1714
Special notes for your reviewer:
WIP because I would still like to write an integration test that causes preemptions from multiple workloads to multiple workloads.
A follow up PR will include rule S2-b, which is not immediately obvious.
Does this PR introduce a user-facing change?
Not yet. The boolean that determines the use of fair sharing is not accessible through any API.
NONE

/assign @mwielgus

This is now ready for review. FYI @tenzen-y

ACK

/hold cancel


Project Catalogue - Missing Projects and Information

Removed the pending ticket from this epic as who knows when there will be capacity to address it. The rest of the ticket has been done for a long time now.


resolve: fixing loader handles calculation

Changelog Description
Resolve was not correctly calculating duration of database related duration.
Additional info
Processing following comment https://github.com/ynput/OpenPype/pull/5665#discussion_r1381631418
Testing notes:

Load clip into Resolve but activate with handles in loader plugin option.

For some reason, I am able to publish work files only. Creators do nothing in Resolve.

Loader still loads the instance with handles, regardless the option is selected or not.

Thanks @BigRoy this had been fixed doe your's suggestion and is mergable now.


Create banking_system_app.java

It is a general Banking System App made in Java programming language.
You can run the program in a simple Java compiler either on online available sites or on your own IDE.
Use it and enjoy😊.

PR accepted @Tanay-Dwivedi
Successfully merged to HacktoberFest_22 repo.
Need to Star this repo incase not done.
🚀🚀👍

PR accepted @Tanay-Dwivedi Successfully merged to HacktoberFest_22 repo. Need to Star this repo incase not done. 🚀🚀👍

Thank you for merging the code.
staring of the repo, done👍🏻
@py3-coder


Chef::Config[:client_key] being set to nil, breaks chef-client recipe

We ran into an issue when running ChefSpec against our base cookbook that includes running the chef-client cookbook.
chef-client::delete_validation runs File.exists?(Chef::Config[:client_key]) to check for a client key. But since it is being set to nil inside of ChefSpec::Runner, it fails with the following error:
Failure/Error: ChefSpec::Runner.new(platform: platform, version: version, log_level: :error).converge(described_recipe)
     TypeError:
       can't convert nil into String
     # /var/folders/7m/p10c4zdx7v16x1_czkg80kw00000gp/T/d20140228-834-1s0yd2s/chef-client/recipes/delete_validation.rb:28:in `exists?'
     # /var/folders/7m/p10c4zdx7v16x1_czkg80kw00000gp/T/d20140228-834-1s0yd2s/chef-client/recipes/delete_validation.rb:28:in `block (2 levels) in from_file'
     # ./spec/default_spec.rb:8:in `block (5 levels) in <top (required)>'
     # ./spec/default_spec.rb:41:in `block (5 levels) in <top (required)>'

I found issue #237 that mentions this is being done on purpose to keep :search from breaking.
Stubbing out include_recipe('chef-client::delete_validation') to return true does allow ChefSpec to run, but then expect(chef_run).to include_recipe('chef-client::delete_validation') fails due to the recipe not showing up in the run_list (Separate bug?).
Failure/Error: expect(chef_run).to include_recipe('chef-client::delete_validation')
       expected ["base::chef-client", "chef-client::service", "chef-client::upstart_service", "chef-client::config"] to include "chef-client::delete_validation"
     # ./spec/chef-client_spec.rb:23:in `block (5 levels) in <top (required)>'

This can reproduced simply by adding include_recipe chef-client::delete_validation to a cookbook.

I'm having a similar issue.  Was this ever solved?

For people who (like me) landed here from Google, here's how I fixed it on my setup:
  let(:chef_run) do
    runner = ChefSpec::SoloRunner.new(platform: 'ubuntu', version: '14.04') do
      Chef::Config[:client_key] = "/etc/chef/client.pem"
    end
    runner.converge described_recipe
  end


FYI - chrome extension released which blocks ip leaks

A VPN provider released their own Chrome extension which now blocks webrtc leaks. Not sure how easy to circumvent though.
Extension
Confirmed blocking in demos here & here.

Don't worry, it has been bypassed, as I commented in the review.

Updated to bypass this extension.

Huh, thank you @upsuper.


'gatsby develop' fails when wordpress site language is set to Russian: Missing onError handler for invocation 'building-schema'

Hi!
I'm facing an error: gatsby develop fails when site language is set to Russian id wordpress admin panel.
If I switch site language to English (UK) - gatsby develop doesn't fail and static site is generated as expected.
Not sure if this error relates to gatsby-source-wordpress-experimental or WP Gatsby/WP GraphQL.
Environment:

Wordpress: 5.5.3
wp theme: twenty-twenty
Site language: Russian
gatsby: 2.25.0
gatsby-source-wordpress-experimental: 7.0.3
WP Gatsby: 0.9.2
WP GraphQL: 1.1.3

Error message
ERROR

Missing onError handler for invocation 'building-schema', error was 'Names must
match /^[_a-zA-Z][_a-zA-Z0-9]*$/ but "WpTemplate_Шаблон обложки" does not.'.
Stacktrace was 'GraphQLError: Names must match /^[_a-zA-Z][_a-zA-Z0-9]*$/ but
"WpTemplate_Шаблон обложки" does not.
    at isValidNameError
(C:\projects\artelx\node_modules\graphql\utilities\assertValidName.js:42:12)
    at assertValidName
(C:\projects\artelx\node_modules\graphql\utilities\assertValidName.js:21:15)
    at checkIsAllowedTypeName
(C:\projects\artelx\node_modules\gatsby\src\schema\schema.js:578:3)
    at forEach
(C:\projects\artelx\node_modules\gatsby\src\schema\schema.js:284:9)
    at Array.forEach (<anonymous>)
    at addTypes
(C:\projects\artelx\node_modules\gatsby\src\schema\schema.js:246:9)
    at updateSchemaComposer
(C:\projects\artelx\node_modules\gatsby\src\schema\schema.js:135:9)
    at buildSchema
(C:\projects\artelx\node_modules\gatsby\src\schema\schema.js:62:9)
    at build (C:\projects\artelx\node_modules\gatsby\src\schema\index.js:105:24)
    at buildSchema
(C:\projects\artelx\node_modules\gatsby\src\services\build-schema.ts:19:3)'

Hi,
I suppose "WpTemplate_Шаблон обложки" is a page template that you use, and it uses Cyrillic characters. I've reproduced your issue, and it does not seem to depend on a site language, and I'm not sure how it fixes it in your case (doesn't in mine).
The problem is, WPGraphQL creates a type for each page template, and a GraphQL type can only be alphanumeric. WPGraphQL changes type names to make them safe, but for some reason it doesn't work with Cyrillic names at all. That's likely a bug, and it's on WPGraphQL's side.
So when graphql on Gatsby's side validates schema and finds this field, it crashes.
A workaround (only one I can come up with now) I can suggest just renaming the template (change it within the template file, without changing the file name itself). After assigning it an alphanumeric name, it works.

Hi,
I suppose "WpTemplate_Шаблон обложки" is a page template that you use, and it uses Cyrillic characters. I've reproduced your issue, and it does not seem to depend on a site language, and I'm not sure how it fixes it in your case (doesn't in mine).
The problem is, WPGraphQL creates a type for each page template, and a GraphQL type can only be alphanumeric. WPGraphQL changes type names to make them safe, but for some reason it doesn't work with Cyrillic names at all. That's likely a bug, and it's on WPGraphQL's side.
So when graphql on Gatsby's side validates schema and finds this field, it crashes.
A workaround (only one I can come up with now) I can suggest just renaming the template (change it within the template file, without changing the file name itself). After assigning it an alphanumeric name, it works.

Thanks for the reply and investigation!
"WpTemplate_Шаблон обложки" - is a default name in twenty-twenty theme in Russian, didn't change it.
Most likely WPGraphQL uses msgstr for page template, and it's in Cyrilic (in case of Russian). Will check WPGraphQL for similar issue or create a new one.
For further information:
It worked fine with this configuration:

Wordpress: 5.5.3 -> same version
wp theme: twenty-twenty -> same version
Site language: Russian -> the same
gatsby: 2.24.63
gatsby-source-wordpress-experimental: 1.4.6
WP Gatsby: 0.4.*
WP GraphQL: 0.3.1

Thanks for the reply and investigation!
"WpTemplate_Шаблон обложки" - is a default name in twenty-twenty theme in Russian, didn't change it.
Most likely WPGraphQL uses msgstr for page template, and it's in Cyrilic (in case of Russian). Will check WPGraphQL for similar issue or create a new one.
For further information:
It worked fine with this configuration:

Wordpress: 5.5.3 -> same version
wp theme: twenty-twenty -> same version
Site language: Russian -> the same
gatsby: 2.24.63
gatsby-source-wordpress-experimental: 1.4.6
WP Gatsby: 0.4.*
WP GraphQL: 0.3.1

Ahh, yep good investigation and this is indeed an upstream issue. It might also be worth asking about this on the Gatsby repo - WPGraphQL seems to be fine with Cyrilic characters in type names but Gatsby does not. The only thing is I'm not sure if this is coming from graphql-js or Gatsby itself :thinking:
In any case I'm going to close this because there's nothing that can be done in this plugin to fix it and either fix will be upstream. Thanks for opening this issue!


Hang after attempting to open wallet with incorrect public passphrase

Discovered by @marcopeereboom.
If the incorrect public passphrase is entered, and then the user attempts to continue opening the wallet with the correct public passphrase, the application hangs trying to open the wallet.

This appears to be a hang when calling the gRPC stub function for the WalletLoaderService.OpenWallet RPC a second time.  There's a good chance this is a hang in the dcrwallet RPC server so I'll start there.

Confirmed.  The wallet process is attempting to open the database twice and this causes the hang.

decred/dcrwallet#288

Once the dcrwallet fix is in, the required RPC semver needs to be bumped here so we know we are connecting to a patched wallet server.


The Aglaus Theme Demo is broken on the Hugo Themes website.

Hello @dim0627
Currently your theme demo fails because since https://github.com/gohugoio/hugo/commit/7930d2132a3c36c1aaca20f16f56978c84656b0a support for .Source has been removed from Hugo 0.50
In your theme's templates please replace all instances of .Source.Path with .File.Path so that your theme's demo is generated once again.
The above replacement should be done to the following templates:
line 12 of layouts/_default/single.html
line 1 of layouts/_default/li.html
line 1 of layouts/_default/li_sm.html
line 1 of layouts/_default/summary.html
line 19 of layouts/_default/baseof.html

Please do this and let me know.
Thanks!
CC / @digitalcraftsman

@dim0627 I assume that you also want this theme removed as you said for your other Hugo themes:
https://github.com/dim0627/hugo_theme_solit/issues/9#issuecomment-437540288
https://github.com/dim0627/hugo_theme_robust/issues/37#issuecomment-437540264
Thank you for your reply.

Yes, I think these themes should removed from Hugo Themes because last maintain too old.
Thank you.


httparty ain't part of gem dependencies

They trying to use this package, I get:
/app/vendor/bundle/ruby/2.7.0/gems/brwiki-0.0.2/lib/brwiki.rb:1:in `require': cannot load such file -- httparty (LoadError)
\tfrom /app/vendor/bundle/ruby/2.7.0/gems/brwiki-0.0.2/lib/brwiki.rb:1:in `'

httparty is not defined as a dependency.

Try downloading the gem again.
I just put a new version with this bug fixed


fact cache write-back not working for files.directory

Describe the bug
It appears different keys into the host.facts cache are (sometimes ?) used depending on whether a fact is being retrieved or an operation is trying to update the fact cache with host.create_fact.
The example below uses permissions on a directory but the behaviour seems to be more general.
From what I can tell, there are couple of items that contribute to the cache keys being different between a 'get' and a 'set':

When host.create_fact(...) is called from inside an operation, the kwargs dict has an entry for each 'global argument' (e.g _su) whereas when host.get_fact(...) is called from the deploy, the kwargs dict has only what is passed by the caller (e.g. path in the case of files.directory).

Host.create_fact  does not have an *args parameter whereas Host.get_fact does.  While this might not matter as as kwargs comes after args and it appears only the values are hashed, but there would seem to be a possible ordering problem once (1) is resolved.

To Reproduce
The code below checks the permissions on a directory, changes them and then reads back what is expected to be the new value
It was run as rmdir foo && mkdir foo && pyinfra @local ./test.py
Code
test.py
from pathlib import Path
from pprint import pformat

from pyinfra import host, logger
from pyinfra.api import deploy
from pyinfra.facts.files import Directory
from pyinfra.operations import files

BEFORE = 755
AFTER = 644

@deploy("test deploy")
def test() -> None:
    test_dir = Path(".") / "foo"
    assert test_dir.exists()

    print("fact cache before any code executed")
    print(pformat(host.facts) + "\n")

    if host.get_fact(Directory, test_dir.name)["mode"] != BEFORE:
        logger.error(f"failed before change, expect mode of {BEFORE} to start")
    print("fact cache after 1st mode check")
    print(pformat(host.facts) + "\n")

    if host.get_fact(Directory, test_dir.name)["mode"] != BEFORE:
        logger.error(f"failed before change, expect mode of {BEFORE} to start")
    print("fact cache after 2nd mode check")
    print(pformat(host.facts) + "\n")

    files.directory(test_dir.name, mode=AFTER, present=True)
    print("fact cache after mode change")
    print(pformat(host.facts) + "\n")

    if host.get_fact(Directory, test_dir.name)["mode"] != AFTER:
        logger.error(f"failed after change, expected mode of {AFTER} after change")
    print("fact cache after 2nd mode check")
    print(pformat(host.facts) + "\n")

test()

Output
--> Loading config...
--> Loading inventory...

--> Connecting to hosts...
    [@local] Connected

--> Preparing operations...
    Loading: ./test.py
fact cache before any code executed
{}

fact cache after 1st mode check
{'2c74fd9a65f89776b451e19964302d186ce4870c': {'atime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'ctime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'group': 'staff',
                                              'mode': 755,
                                              'mtime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'size': 64,
                                              'user': 'james'}}

fact cache after 2nd mode check
{'2c74fd9a65f89776b451e19964302d186ce4870c': {'atime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'ctime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'group': 'staff',
                                              'mode': 755,
                                              'mtime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'size': 64,
                                              'user': 'james'}}

fact cache after mode change
{'2c74fd9a65f89776b451e19964302d186ce4870c': {'atime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'ctime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'group': 'staff',
                                              'mode': 755,
                                              'mtime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'size': 64,
                                              'user': 'james'},
 'ec262d81820a25c8da29b49a6f4850c79101c427': {'atime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'ctime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'group': 'staff',
                                              'mode': 644,
                                              'mtime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'size': 64,
                                              'user': 'james'}}

  failed after change, expected mode of 644 after change
fact cache after 2nd mode check
{'2c74fd9a65f89776b451e19964302d186ce4870c': {'atime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'ctime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'group': 'staff',
                                              'mode': 755,
                                              'mtime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'size': 64,
                                              'user': 'james'},
 'ec262d81820a25c8da29b49a6f4850c79101c427': {'atime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'ctime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'group': 'staff',
                                              'mode': 644,
                                              'mtime': datetime.datetime(2022, 8, 2, 22, 6, 32),
                                              'size': 64,
                                              'user': 'james'}}

    [@local] Ready: ./test.py

--> Proposed changes:
    Groups: @local
    [@local]   Operations: 1   Change: 1   No change: 0

--> Beginning operation run...
--> Starting operation: test deploy | Files/Directory (foo, mode=644, present=True)
    [@local] Success

--> Results:
    Groups: @local
    [@local]   Changed: 1   No change: 0   Errors: 0

Expected behavior
I expected:
a) only one entry in the fact cache at each output (vs. the two that are seen) and
b) the permissions to be  expected values at each step
Meta
pyinfra was installed with git clone ..., cd pyinfra and pip install -e '.[dev]'
git describe --tags gives: v2.3-25-g5fedec46
pyinfra --support gives:
    System: Darwin
      Platform: macOS-11.6.8-x86_64-i386-64bit
      Release: 20.6.0
      Machine: x86_64
    pyinfra: v2.3
    Executable: /Users/james/.virtualenvs/pyinfra/bin/pyinfra
    Python: 3.10.2 (CPython, Clang 13.0.0 (clang-13<IP_ADDRESS>))

So the reason the global arguments are part of the hash is to account for fact results being different depending on them (eg sudo/not sudo). But as you point out this essentially means facts are only good within the context of an operation, they won't correctly invalidate other facts for the same thing called without those arguments.
Perhaps a good fix would be to always use the default set of global arguments in facts, which would address the example above.
Regarding point 2 the args are converted to kwargs, they're only supported for backwards compatibility:
https://github.com/Fizzadar/pyinfra/blob/7cc0e02149106d561df3f6acba390e20b7f7c1c5/pyinfra/api/facts.py#L206-L209

Spotted the kwargs/args here - calling with args/kwargs does indeed generate a different hash because the normalisation I referenced above happens after the hash generation. Fixed in https://github.com/Fizzadar/pyinfra/commit/bc06372d58c5178dd13402f196a3b6b8e84d6e2e.
I have fixed the default arguments thing in https://github.com/Fizzadar/pyinfra/commit/d6c3db64383b0a8f81c3b649d72aa8bcba8999ce, and now the test script above executes as expected.

Fixes are now live in v2.5.2 :)


Modal Dialog fires dismiss on close

Prerequisites

[X] I have not leaked any internal company information.
[X] I have not posted internal links or code snippets.

What happened?
When closing a Modal Dialog using IxActiveModal.close(reason) method, a dismiss event is fired additionally.
This leads into unexpected behavior as the dismiss event is also subscribed.
The stackblitz example shows, that closing a modal dialog (by x, cancel, ok) leads into 2 events, where the second event is always 'dismiss'.
What type of frontend frameware are you seeing the problem on?
Angular
Which version of iX do you use?
v2.1.0
Code to produce this issue.
https://stackblitz.com/edit/k5zpnl-dgfcmz

Thanks for your report we will have a look into it! Internal ref [IX-985]


[SILGen] Fixed handler formal arg type indexing.

In the synthesized completion handler that is passed to ObjC methods that are called as async, the formal type of each argument is the corresponding parameter of the formal type of the block.  The non-error, non-index arguments need to be prepared so that they can be used to fulfill the continuation; the lambda which does that preparation for each such argument takes the formal type of that argument.  As such, the call to that lambda needs to pass the type of the corresponding parameter of the formal type of the block to that lambda.  Doing so entails skipping over the error and flag parameters if they appear before some of the non-error, non-index arguments.
Previously, no parameters were skipped over.  Consequently, when an error or flag argument preceded one of the non-error, non-index arguments, the wrong formal type was passed to the preparation lambda.
Here, that is fixed by passing the correct index.  The to-be-used indices for the formal block parameters are the same as the to-be-used indices for the lowered block parameters minus one reflecting the fact that the lowered block always has an initial block_storage parameter as the first argument which the formal type never has.
rdar://81617749

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha -<PHONE_NUMBER>115ca4980e339789bf19bbcf807c9c

@swift-ci please clean test linux platform

Build failed
Swift Test OS X Platform
Git Sha -<PHONE_NUMBER>115ca4980e339789bf19bbcf807c9c

@swift-ci please test

@swift-ci please clean test windows platform

Build failed
Swift Test OS X Platform
Git Sha - 5e352f81baba19a7a9888658aa74533baee4ca2e

@swift-ci please test

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - cef64c9c44ecdf6ee95866bbbb8d4c72611973c2

@swift-ci please clean test macos platform


BukkitUnTrustEvent doesn't seem to get called

Hello!
I am currently integrating the HuskClaims Plugin API into one of my plugins. For better detection I wanted to use the BukkitUnTrustEvent. But I can't get it to fire an Event. I am not familiar with the plugin. So a problem from my site is possible.
I tried /huskclaims:untrust %user%
After running /permissiontrust %user% or /trust %user%
It is registered and other events from HuskClaims are getting fired.
Eventhandler is also above the Event.

I can't seem to see what would be causing this to straight up not fire. Have you registered your Event Listener?

Here is a Screenshot from my class. The Class is registered and the other events getting fired.

I am using the version: HuskClaims-Paper-1.1.2-d181297-indev.jar

Any news about that?

Could you try reproducing with the latest compiled version of HuskClaims? I simply can't repro this :(