Generate tiny compiled binary for wrapping executables

Generate tiny compiled binary for wrapping executables
Motivation for this change
Nix uses bash-wrappers to inject custom environment variables into executables. In the cases where this executable is an interpreter (like Python or Perl), it can be placed in the shebang line of a script. On MacOS, you can't put a script (with its own shebang) in the shebang line of an executable due to a limitation with the execve-syscall.
If we had some way of generating tiny compiled binaries instead of bash-scripts as wrappers then this would work on both Linux and MacOS.
See https://github.com/NixOS/nixpkgs/issues/23018 for more discussion.
A focus in this PR has been to minimize the number of dependencies - and also keep the implementation itself as minimal as possible.
Dependencies

bash
A C-compiler: gcc on Linux or clang on MacOS
unistd + stdlib + string (C libraries)

Consider the following wrapper shell script:
#! /nix/store/ra8yvijdfjcs5f66b99gdjn86gparrbz-bash-4.4-p23/bin/bash -e
export NIX_PYTHONPREFIX='/nix/store/i46k148mi830riq4wxh49ki8qmq0731k-python3-3.9.2-env'
export NIX_PYTHONEXECUTABLE='/nix/store/i46k148mi830riq4wxh49ki8qmq0731k-python3-3.9.2-env/bin/python3.9'
export NIX_PYTHONPATH='/nix/store/i46k148mi830riq4wxh49ki8qmq0731k-python3-3.9.2-env/lib/python3.9/site-packages'
export PYTHONNOUSERSITE='true'
exec "/nix/store/7pjbbmnrch7frgyp7gz19ay0z1173c7y-python3-3.9.2/bin/python"  "$@"

Putting this script in a shebang works fine on Linux, but doesn't work on MacOS. If we want to write C-code that replaces it (and works on MacOS+Linux), we can do it like this in C:
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char** argv) {
    putenv("NIX_PYTHONPREFIX=/nix/store/i46k148mi830riq4wxh49ki8qmq0731k-python3-3.9.2-env");
    putenv("NIX_PYTHONEXECUTABLE=/nix/store/i46k148mi830riq4wxh49ki8qmq0731k-python3-3.9.2-env/bin/python3.9");
    putenv("NIX_PYTHONPATH=/nix/store/i46k148mi830riq4wxh49ki8qmq0731k-python3-3.9.2-env/lib/python3.9/site-packages");
    putenv("PYTHONNOUSERSITE=true");
    argv[0] = "/nix/store/7pjbbmnrch7frgyp7gz19ay0z1173c7y-python3-3.9.2/bin/python";
    return execv(argv[0], argv);
}

This PR has creates a simple bash function that generates C-code for such a tiny compiled binary (and compiles it), with an interface similar to the existing makeWrapper. There are some features of the original makeWrapper which is not yet implemented here.
Debuggability
A big concern with using a binary wrapper is that people can't just open up the file to see what it is doing when debugging their own problems. This is fixed by embedding the source code as a string variable into the source code itself (code-ception). The result is that the binary file will contain the source code in human readable format when opening the file in a plain text editor or using the strings command on MacOS or Linux.
Example of how it looks right now:
makeBinaryWrapper /usr/bin/python3 ./wrapper \
  --set HELLO WORLD --set-default X $'Y\n"' --unset Z --argv0 python3

cat ./wrapper

...binary-data...
----------
// This binary wrapper was compiled from the following generated C-code:
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    putenv("HELLO=WORLD");
    setenv("X", "Y\n\"", 0);
    unsetenv("Z");
    argv[0] = "python3";
    return execv("/usr/bin/python3", argv);
}
----------
...binary-data...

C String literals in the generated code (including the documentation) are properly escaped. I got some help with how to do this properly on StackOverflow: https://stackoverflow.com/questions/67710149/how-can-i-sanitize-user-input-into-valid-c-string-literals.
Generated source code example
makeDocumentedCWrapper /usr/bin/python3 --set HELLO WORLD --set-default X $'Y\n"' --unset Z --argv0 python3

#include <unistd.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    putenv("HELLO=WORLD");
    setenv("X", "Y\n\"", 0);
    unsetenv("Z");
    argv[0] = "python3";
    return execv("/usr/bin/python3", argv);
}

const char * SOURCE_CODE = "\n----------\n// This binary wrapper was compiled from the following generated C-code:\n#include <unistd.h>\n#include <stdlib.h>\n\nint main(int argc, char **argv) {\n    putenv(\"HELLO=WORLD\");\n    setenv(\"X\", \"Y\\n\\\"\", 0);\n    unsetenv(\"Z\");\n    argv[0] = \"python3\";\n    return execv(\"/usr/bin/python3\", argv);\n}\n----------\n";

Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[x] Fits CONTRIBUTING.md.

Issues that this PR would likely impact:

https://github.com/NixOS/nixpkgs/issues/2146
https://github.com/NixOS/nixpkgs/issues/11133
https://github.com/NixOS/nixpkgs/issues/23018
https://github.com/NixOS/nixpkgs/issues/65351
https://github.com/NixOS/nixpkgs/issues/86881
https://github.com/NixOS/nixpkgs/issues/93609
https://github.com/NixOS/nixpkgs/issues/123067

see https://github.com/NixOS/nixpkgs/pull/95569 for prior art

I love this! It took a moment of fiddling about but I used the default makeWrapper, this PR's makeBinaryWrapper, and makeBinaryWrapper from #95569, and got this:
-r-xr-xr-x 1 root root  80128 Dec 31  1969 binary-nim
-r-xr-xr-x 1 root root    291 Dec 31  1969 current
-rwxr-xr-x 1 haro users 14232 Dec 31  1969 binary-c

so while this is significantly heavier than the shell-script version (unsurprisingly — the debug string literal is going to be around the size of the script) it's significantly smaller than the one that depends on nim and its json libraries and such, so I think it's seriously worth considering this over that (the operation of this executable is also more straightforward IMO).
On the other hand, that one has much more features. Looking at the current uses of makeWrapper, I think you'll have to add --add-flags, --prefix, and --suffix at least to support most use cases.

@hrhino Thanks for the feedback!
I've added --add-flags, --prefix and --suffix now, without impacting the resulting binary size too much. They were slightly more involved than the previous ones - but hopefully the generated code should still be relatively easy enough to read/understand.
I turned on -Os (optimize for small size) to keep the binary size small. It didn't help much in making the binaries smaller - but it helped in preventing them from getting bigger when I added the functions I use for --prefix and --suffix.
Although the compiler will automatically discard functions that are not being used - the debug string won't - so in order to keep the debug string clean - I only include the functions used by --prefix and --suffix if they are actually used.

In terms of memory safety
As long as the wrapper is executed as its own process, the OS will take care of freeing any remaining memory when the process exits. So if there are memory leaks in the wrapper, it will simply add an additional constant overhead to the process that has been wrapped.
It is not possible to free things like the argv that was passed to main, even if the child process does not use it - so some memory overhead from wrapping seems unavoidable.
We can only safely free memory that is not used by the wrapped program. That essentially means only "temporary" variables can be freed. From the code I've written so far, the only temporary variable that is not consumed by the wrapped process is the result of char *concat3(char *x, char *y, char *z);.
The reason val can be freed after calling setenv(key, val, 1); is that setenv creates its own internal copy of val. Since we are not allowed to free environment variables passed from the parent process, we must make sure to only free val if it is the result of char *concat3(char *x, char *y, char *z);

I'm not concerned about memory leaks either, but I am concerned about undefined behavior.
Seemingly innocent mistakes can lead to security problems, amplified by the fact that such a simple core component would be assumed to be trustworthy by many.
Even just the "golden test" idea goes a long way when it comes to this responsibility, because it will let maintainers check the generated programs manually and help us check them again when the code generation inevitably needs to change.

This looks so great :) A few comments, first of all:
diff --git i/pkgs/top-level/all-packages.nix w/pkgs/top-level/all-packages.nix
index c53485f5dea..30b38909952 100644
--- i/pkgs/top-level/all-packages.nix
+++ w/pkgs/top-level/all-packages.nix
@@ -642,6 +642,8 @@ with pkgs;
   makeWrapper = makeSetupHook { deps = [ dieHook ]; substitutions = { shell = targetPackages.runtimeShell; }; }
                               ../build-support/setup-hooks/make-wrapper.sh;

+  makeBinaryWrapper = makeSetupHook { } ../build-support/setup-hooks/make-binary-wrapper.sh;
+
   makeModulesClosure = { kernel, firmware, rootModules, allowMissing ? false }:
     callPackage ../build-support/kernel/modules-closure.nix {
       inherit kernel firmware rootModules allowMissing;

And then it's easy to test this with:
env NIX_PATH=nixpkgs=$PWD nix-shell -p makeBinaryWrapper --run makeBinaryWrapper <args>

Or even without the need to clone and checkout your branch:
env NIX_PATH=nixpkgs=https://github.com/bergkvist/nixpkgs/archive/bergkvist/make-c-wrapper.tar.gz nix-shell -p makeBinaryWrapper --run makeBinaryWrapper <args>

It'd be nice to put that info in the first comment of the thread :).
Other then that, When giving a try to --prefix, I forgot to give 3 arguments (forgot the separator) and it took me a while to realize it failed silently to wrap properly the executable - it'd be nice if the bash function would have checked it received a proper number of arguments for each option.

@doronbehar Thanks for the suggestion! I added it to pkgs/top-level/all-packages.nix, and put the command you suggested at the top of the first comment of this PR.
Detecting whether the wrong number of arguments are passed could be tricky - especially if it is not the last element. That said, I added a check to make it not fail silently if the number of arguments don't add up.

Golden tests
I've created a system for writing golden tests for makeBinaryWrapper. I added tests to at least cover every type of argument. For the time being, I copy-pasted some of the testing logic from the patch-shebangs-test.
Running the tests on Linux
git clone https://github.com/bergkvist/nixpkgs bergkvist-nixpkgs
cd bergkvist-nixpkgs
git checkout bergkvist/make-c-wrapper
nix-build pkgs/top-level/release.nix -A tests.make-binary-wrapper.x86_64-linux

Example test
// makeCWrapper /hello/world \
    --set PART1 HELLO \
    --set-default PART2 WORLD \
    --unset SOME_OTHER_VARIABLE \
    --set PART3 $'"!!\n"'

#include <unistd.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    putenv("PART1=HELLO");
    setenv("PART2", "WORLD", 0);
    unsetenv("SOME_OTHER_VARIABLE");
    putenv("PART3=\"!!\n\"");
    argv[0] = "/hello/world";
    return execv("/hello/world", argv);
}

Notice that the first comment serves as the input command (after // has been stripped away). Having both the input command and the generated code in the same file makes it easier to create new tests or modify existing ones.
The backslashes serve a dual purpose:

Allow for writing the input command using more than one line
Ensure that the input command remains a comment when using C syntax highlighting, in spite of being spread across multiple lines.

In terms of memory safety - as an alternative to CodeHawk-C, we could also consider using infer by Facebook. (Downside: not as lightweight)
Here is an example to demonstrate null pointer dereferencing and buffer overrun issues:
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv) {
    char **argv_tmp = malloc(sizeof(*argv_tmp) * (4 + argc));
    argv_tmp[0] = argv[0];
    argv_tmp[1] = "-x";
    argv_tmp[2] = "-y";
    argv_tmp[3] = "-z";
    for (int i = 1; i < argc; ++i) {
        argv_tmp[5 + i] = argv[i];
    }
    argv_tmp[4 + argc] = NULL;
    argv = argv_tmp;

    argv[0] = "my-wrapper";
    return execv("/path/to/executable", argv);
}

Command:
infer run --biabduction --bufferoverrun -- gcc -c main.c
Capturing in make/cc mode...
Found 1 source file to analyze in /home/tobias/infer-test/infer-out
1/1 [################################################################################] 100% 167ms

main.c:14: error: Buffer Overrun L1
  Offset: `argc` + 4 Size: `argc` + 4.
  12.         argv_tmp[5 + i] = argv[i];
  13.     }
  14.     argv_tmp[4 + argc] = NULL;
          ^
  15.     argv = argv_tmp;
  16.

main.c:12: error: Buffer Overrun L2
  Offset: [6, `argc` + 4] Size: `argc` + 4.
  10.     argv_tmp[3] = "-z";
  11.     for (int i = 1; i < argc; ++i) {
  12.         argv_tmp[5 + i] = argv[i];
              ^
  13.     }
  14.     argv_tmp[4 + argc] = NULL;

main.c:7: error: Null Dereference
  pointer `argv_tmp` last assigned on line 6 could be null and is dereferenced at line 7, column 5.
  5. int main(int argc, char **argv) {
  6.     char **argv_tmp = malloc(sizeof(*argv_tmp) * (4 + argc));
  7.     argv_tmp[0] = argv[0];
         ^
  8.     argv_tmp[1] = "-x";
  9.     argv_tmp[2] = "-y";

Found 3 issues
            Issue Type(ISSUED_TYPE_ID): #
    Null Dereference(NULL_DEREFERENCE): 1
  Buffer Overrun L2(BUFFER_OVERRUN_L2): 1
  Buffer Overrun L1(BUFFER_OVERRUN_L1): 1

In order to fix these issues, I can then do:
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>

int main(int argc, char **argv) {
    char **argv_tmp = malloc(sizeof(*argv_tmp) * (4 + argc));
    assert(argv_tmp != NULL);
    argv_tmp[0] = argv[0];
    argv_tmp[1] = "-x";
    argv_tmp[2] = "-y";
    argv_tmp[3] = "-z";
    for (int i = 1; i < argc; ++i) {
        argv_tmp[3 + i] = argv[i];
    }
    argv_tmp[3 + argc] = NULL;
    argv = argv_tmp;

    argv[0] = "my-wrapper";
    return execv("/path/to/executable", argv);
}

Capturing in make/cc mode...
Found 1 source file to analyze in /home/tobias/infer-test/infer-out
1/1 [################################################################################] 100% 227ms

  No issues found

A relevant takeaway:
Infer static analysis wants us to check that the returned value from malloc is not a NULL pointer. If malloc fails, we probably want to crash anyways - so we can use assert to be explicit about this behaviour. If malloc actually fails - then we will also get much better error messages when using assert:
[1]    1020278 segmentation fault (core dumped)  ./a.out

vs
a.out: main.c:8: main: Assertion `argv_tmp != NULL' failed.
[1]    1020411 abort (core dumped)  ./a.out

Thanks for the review @pennae! And for the helpful comments @samueldr and @andrew-d. I think I've addressed all of the latest comments now, so feel free to take another look if you want.

@bergkvist hi i just had a look at this after @roberth sent me this PR because of a completely different topic. I am really interested in getting this in, but i would change a few things.

how about making the golden tests not compare actual source code but test the effect on the wrapped binary/script: this way we would not need to change all the tests on every single change. Also, we want to test if the effect that the wrapper has on the wrapped app is correct - users don't care about the C code as long as it's correct.
what do you think about splitting the C-code generating script: have a script that only emits the generated code, and have another script compile it. this would make it easier to feed the output to static analysis, add sanitizers for tests builds etc. etc., i don't think that the script needlessly mixes multiple concerns right now.

regardless of how the tests look in the end, i think we should have as a minimum requirement that we compile the output at least with -Wall -Wpedantic -Werror and add -fsanitize=address -fsanitize=undefined and run the wrappers to see if any sanitizer triggers.
the sanitizer can be instructed to ignore memory leaks using
export ASAN_OPTIONS=detect_leaks=0

Yeah my suggestion to golden-test the generated source was as a poor man's verification. If we can verify memory-correctness automatically, we don't need to golden-test the generated sources.

How would we verify that the wrapper didn't modify some unexpected environment variable?

the test can start the wrapper in an empty environment, eg env -i

can we also directly aim towards being able to substitute makeWrapper? i would really like to be able to have an overlay like final: prev: { makeWrapper = prev.makeBinaryWrapper; } and build my systems like that.

@tfc makeWrapper is part of stdenv, so that's a big change that has to go into staging. It's more efficient to complete this work on master first and then create a new PR for stdenv targeting staging.

In terms of feature parity with makeWrapper (to allow substitution), there are a few things which will not work/be the same:

--run "..."-commands which changes directory, or accesses/changes the environment/sources a bash script
--argv0 '$0' -> Commands which take advantage of how the bash runtime will expand expressions like environment variables.

In general, anything which relies on the inner workings of bash/makeWrapper, rather than strictly on the makeWrapper interface will be hard (and possibly not desirable) to port over.

things that we should add:

set -euo pipefail in the script
-Werror -Wall -Wpedantic is a must
let the user choose/override the compiler
let the user choose to enable/disable -fsanitize=address -fsanitize=undefined

@roberth did you notice we've had 2 review discussions left open? They are an indicator that makeWrapper doesn't work on Darwin because of the sanitizers enabled and even on Linux they are a too big performance price to pay for safety.

@doronbehar I didn't notice the discussion about the failure on macOS, which I should have. The other discussion seemed resolved because this addition is not a performance regression and the trade-off can be adjusted later. Then also the PR already had two approvals and the CI was all-green.

The other discussion seemed resolved because this addition is not a performance regression and the trade-off can be adjusted later.

It's just that the sanitizing seems to break the build on Darwin as well, besides the stdenv.cc issue, as mentioned in @bergkvist comment: https://github.com/NixOS/nixpkgs/pull/124556#discussion_r766237818
What do you think @tfc ?

What do you think @tfc ?

So from my perspective there are multiple use cases for this wrapper:

have working wrappers on macos
have static unscripted wrappers on linux
have wrappers that are faster than bash based wrappers

having sanitizers in the binaries by default provides working wrappers (apart from the fact that we need to figure out that one problem on macos with the sanitizers) with a secure default. i think having sanitizers in the tests is not enough because we might have a rest chance to end up with some kind of strange makewrapper flags that lead to an unsafe binary that is not covered by the tests. it's a risk to that then have do strange things instead of loudly exploding.
for the case of "i want fast wrappers" you can simply build a system with the secure ones, see that it works and then rebuild with insecure ones. disabling this security option should most likely be a conscious choice.

Regarding CI, it seems like everything works:

But looking more closely at it, it turns out all the tests were skipped:

So this also needs to be fixed

I've created a new PR to fix the Darwin issues we discussed now: https://github.com/NixOS/nixpkgs/pull/150079

for the case of "i want fast wrappers" you can simply build a system with the secure ones, see that it works and then rebuild without sanitizers. disabling this security option should most likely be a conscious choice.

Alternatively, you could prove correctness using a sound static analyzer. Also, perhaps the functions could form a memory-safe interface, such that the generated code is as simple as possible. That would make it feasible to have a high assurance without performance impact; without even having to run the analyzer as a build dependency in practice (because the functions have already been checked and that check has been cached).

Yeah, static analyzers are an attractive alternative to using sanitizers - since they move the checking from run-time to build time. This means problems are also detected earlier.
A static analyzer can never prove safety in the general case, since this is an undecidable/uncomputable problem. So I guess sanitizers might provide a somewhat stronger protection against undefined behaviour (although at a high cost to performance).
It seems like it is common to combine multiple static analyzers - since they tend to specialize in different areas/detect different kinds of problems. When I tested infer static analyzer and the clang static analyzer on the binary wrapper code - there was for the most part no overlap in the problems they would detect.
infer seemed a lot better than clang at detecting buffer overruns and potential NULL dereferencing for example:

https://fbinfer.com/docs/all-issue-types#buffer_overrun_l1
https://fbinfer.com/docs/all-issue-types#null_dereference

A static analyzer can never prove safety in the general case

I don't think we need the general case.

sanitizers might provide a somewhat stronger protection against undefined behaviour

Only if the analysis is unsound. Undecidability does not exclude soundness and our programs are very simple here, so checking with an analyzer that is sound (but incomplete, as per undecidability) seems feasible.
CodeHawk-C is sound but I don't have experience with it and it hasn't been packaged yet. Maybe other analyzers exist that have the soundness property.

Yes, this is a good point. By having an analyzer that marks everything as potentially unsafe - it would be trivially sound (although not particularly useful). Rather than adding suspicious cases, a sound analyzer would remove things that are provably safe from the pool of potential problems (where everything starts out as potential problems).

It seems like the compilation/tests of makeBinaryWrapper fails on aarch64-darwin, due to some codesign issues. Anyone here with an M1 macbook/that know what this might be about? See the OfBorg logs and  https://github.com/NixOS/nixpkgs/pull/150079 for more info.

Very cool to see this make it into Nixpkgs in some form. Thanks for getting this first version in and for continuing to work to improve this feature! Also thanks to all the reviewers, since this seems like one of the harder changes to review in Nixpkgs and has gotten a lot of work from reviewers. You guys are awesome!

Since it's time to change the way we handle wrappers, I created a new issue to mention another problem that can be problematic with wrappers (namely that $0 points in scripts to the wrapping program instead of the original program, which causes troubles if $0 is used to restart the program later), together with a proposed solution to solve it https://github.com/NixOS/nixpkgs/issues/150841.
Note that as it, this PR does not solve it (nor does https://github.com/NixOS/nixpkgs/pull/150079). Would be great if both issues could be solved at once.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nix-macos-monthly/12330/14

I haven't had a chance to poke at these wrappers yet, but this seems like a fair place to register that I may need a programmatic way to associate them with their wrapped executables.
I noted this tentatively back in nixos/rfcs#75, and at the time I was imagining a metadata dotfile alongside the wrapper. I didn't realize there was work under-way here, and the feature I needed this for has been in nixpkgs for a few months. Luckily I noticed toonn mention this on discourse. 😊
Basically:

resholve uses binlore to collect some information about executables.
part of this analysis maps Shell wrappers to wrapped executables by parsing the exec out of the Shell wrapper in order to associate information derived from the executable with the wrapper as well.


Only application.yml is retrieved when using "organization" notation

Issue:
I'm trying to use the "organization" notation defined here
https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html
For instance:
http://localhost:8888/level1(_)level2(_)sboot-configs(_)prueba1/int
Against a git server with the following files:

application.yml
prueba1-int.yml
prueba1.yml

Everything looks fine until the response is returned:
{
    "name": "level1/level2/sboot-configs/prueba1",
    "profiles": [
        "int"
    ],
    "label": null,
    "version": "60ad6d2d4d4f150a04e34589116891c9d53a323b",
    "state": null,
    "propertySources": [
        {
            "name": "https://myserver:myport/level1/level2/sboot-configs/prueba1-config.git/application.yml",
            "source": {
                "propiedad-generica": "valor_generico"
            }
        }
    ]
}

If I don't use the "organization" notation, and change configuration in order to point to the repo, it retrieves the three files...
I have noticed that the class NativeEnvironmentRepository has a method getArgs, The application parameter has the value level1/level2/sboot-configs/prueba1 .
Do you know how can i solve this in order to use the organization notation?
Thanks a lot in advance.
Kind Regards

would you please paste your config server configuration (formatted please).

Hi Haybt,
Sure. Here it is:
spring:
  cloud:
    config:
      server:
        git:
          uri: https://corporate-gitlab/{application}-config.git
          username: user
          password: pass
          skip-ssl-validation: true
          repos:
              no-prod:
                 pattern:
                   - '*/int'
                   - '*/test'
                 uri: https://corporate-gitlab/{application}-config.git
                 username: user
                 password: pass
                 skip-ssl-validation: true
              prod:
                 pattern:
                   - '*/prod'
                 uri: https://corporate-gitlab/sboot-configs/prod-configs.git
                 username: user
                 password: pass
                 skip-ssl-validation: true
                 search-paths: apps

I'm using latest spring relase (2.1.5 and  Greenwich.SR1)
Thanks a lot in advance!

A typical setup and configuration like yours work just fine for me. I just noticed you segregate environment specific properties in a yaml file with -int postfix. Can you try having one yaml file for an app, for example, prueba1.yml, and inside it segregate environment properties using --- separator and the spring profile(s).
Example
foo: baz
----
spring:
  profiles: int

foo: bar

Hi Haybu,
I will try with it tomorrow morning (CEST Timezone). In the meantime, I have been able to solve it, by developing an aspect with aspectj, intercepting the call to getArgs method, splitting the applicationName (it has the value  level1/level2/sboot-configs/prueba1 at that time), and removing everything from that path except the "prueba1" suffix.
Thanks again

Hi Haybu,
I've finally tried with you suggestion. Unfortunately, It also didn't work. Do you have any other idea?
As I said before, I have handle it using an aspect, but I think it is not the most suitable solution...
Kind regards


Use destructive button style confirm button on alerts for deleting files, turning off printer etc.

Hi! As stated in the title - I think using destructive button style for confirm (Yes) buttons on alerts for file deletion, turning off printer and other dangerous actions would really benefit the UX of the app. This would make the Yes button red and stand out. What do you think? If this is an improvement you like, I'm down to create a PR in the following days.

Hi @SebastianOsinski ,
This sounds like a nice idea. Waiting for the PR to check it out and merge it.
Thanks,
Gaston


Added new Dashboard Object Type.

Noticed an error when listing Workspace folders via the Databricks Client.  It seems to be missing the new 'DASHBOARD' object type.  I would suggest some more elegant way of mashalling the contents of a Workspace folder into the ObjectType object such that it does not error when it sees an item it does not understand - maybe make this an Unknown type.


feat: Migrate /auctions app to Palette v3

Addresses https://artsyproduct.atlassian.net/browse/DSWGW-41
This migrates our new v2 /auctions page to Palette v3.

Sending out....


Bugfix: fixes the usage of negotiationId/contractId

What this PR changes/adds
ContractNegotiationServiceImpl#getForNegotiation now correctly fetches the ContractNegotiation, and if present, returns the attached ContractAgreement or null.
Why it does that
The negotiationId was misinterpreted as cotnractId before.
Further notes
none
Linked Issue(s)
Closes #1140
Checklist

[x] added appropriate tests?
[x] performed checkstyle check locally?
[x] added/updated copyright headers?
[x] documented public classes/methods?
[x] added/updated relevant documentation?
[x] added relevant details to the changelog? (skip with label no-changelog)
[x] formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

Codecov Report

Merging #1142 (5f29abe) into main (f5d8d0a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##               main    #1142   +/-   ##
=========================================
  Coverage     62.63%   62.64%
  Complexity     2973     2973
=========================================
  Files           694      694
  Lines         15420    15421    +1
  Branches       1043     1043
=========================================
+ Hits           9659     9660    +1
  Misses         5332     5332
  Partials        429      429

Impacted Files
Coverage Δ

...iation/service/ContractNegotiationServiceImpl.java
100.00% <100.00%> (ø)

...negotiation/store/SqlContractNegotiationStore.java
87.43% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f5d8d0a...5f29abe. Read the comment docs.


Moving the mouse over the taskbar does not pop up the window title at the first start.

Describe the bug
When the program first starts, moving the mouse over the taskbar does not show the window title.
To Reproduce
Steps to reproduce the behavior:
A.
        <
...............................
        WindowCornerPreference="Round"
        Icon="pack://application:,,,/Logo.png"
        Title="{Binding TitleText}" >

B.
        public string TitleText
        {
            get => _titleText;
            private set
            {
                _titleText = value;
                OnPropertyChanged(nameof(TitleText));
            }
        }

Expected behavior
When the program first starts, the title of the window is displayed when the mouse moves over the taskbar.
Screenshots
When the program first starts, the other controls display TitleText correctly：

Only after starting the software and updating TitleText once will the content pop up when the mouse moves over the taskbar：

Desktop (please complete the following information):

.NET: [net6.0-windows11]
Version: [ 2.0.2]

I assume that the TitleText property is in the ViewModel so your problem is the DataContext, ViewModel is injected (see App.xaml.cs), try putting this in the constructor*:
DataContext = viewModel;

*untested

The Title property of the TitleBar is not connected to the Title property of Window.
https://github.com/lepoco/wpfui/blob/6e8739676867ecce82a7913ed35c2bb63a59672f/src/Wpf.Ui/Controls/TitleBar.cs#L181

I think it is talking about the Title on the TaskBar
This is the default Container.xaml (from demo app):
<ui:UiWindow
    ...
    Title="WPF UI"
    ...
/>

This is the same view with the Title property bound to a property in the ViewModel
<ui:UiWindow
    ...
    Title="{Binding TitleText}"
    ...
/>

private string _titleText = "THIS IS THE TASKBAR!";
public string TitleText
        {
            get => _titleText;
            private set
            {
                _titleText = value;
                OnPropertyChanged(nameof(TitleText));
            }
        }

and this with the ViewModel assigned to the DataContext
// Container.xaml.cs -> Container()
DataContext = viewModel;

am I getting this whole thing wrong? 😄

The Title property of the TitleBar is not connected to the Title property of Window.
https://github.com/lepoco/wpfui/blob/6e8739676867ecce82a7913ed35c2bb63a59672f/src/Wpf.Ui/Controls/TitleBar.cs#L181

What I said is about  in ui:Window and I left  in ui:TitleBar  to be always empty, so there is nothing about  in ui:TitleBar  .
In the issue screenshots, both "TitleLabel" I added and  in ui:Window were bound to "TitleText" in DataBinding, Only "TitleLabel" display the content right after starts( as the first screenshot ), but  of ui:Window seems to be empty. After changed the property of "TitleText" in DataBinding, both of they work well( as the second screenshot).

Maybe later I will put a Minimal Reproduce Demo into this issue.

I think it is talking about the Title on the TaskBar
This is the default Container.xaml (from demo app):
<ui:UiWindow
    ...
    Title="WPF UI"
    ...
/>

This is the same view with the Title property bound to a property in the ViewModel
<ui:UiWindow
    ...
    Title="{Binding TitleText}"
    ...
/>

private string _titleText = "THIS IS THE TASKBAR!";
public string TitleText
        {
            get => _titleText;
            private set
            {
                _titleText = value;
                OnPropertyChanged(nameof(TitleText));
            }
        }

and this with the ViewModel assigned to the DataContext
// Container.xaml.cs -> Container()
DataContext = viewModel;

am I getting this whole thing wrong? 😄

I have assigned the ViewModel  to the DataContext.

I had a discussion with @LHTXQ and came to the funny conclusion.
First, @LHTXQ 's problem is the ToolTip on taskbar rather than the title.
Second, the ToolTip is not controlled by user or by this UI Library but by system.
It will only pop up a caption prompt if the title is too long to display.


Unable to access VueTorrent

Chart Name
qbittorrent
Chart Version
0.3.7
Bug Description
helmfile.yaml
  - name: qbittorrent
    namespace: qbittorrent
    chart: oci://ghcr.io/gabe565/charts/qbittorrent
    version: 0.3.7
    values:
      - env:
          TZ: Europe/Budapest
          DOCKER_MODS: ghcr.io/gabe565/linuxserver-mod-vuetorrent
      - persistence:
          vuetorrent:
            enabled: true
            type: emptyDir

I have the following configuration and I don't see where to access the VueTorrent web interface.
When I open the webui using a port-forward ot my pod all I get is: Unauthorized with a 401 status reply. Not prompted even for http basic auth or anything. I didn't find any further information on artifacthub how to access the webui, so I would ask for some help here.
values.yaml
- env:
    TZ: Europe/Budapest
    DOCKER_MODS: ghcr.io/gabe565/linuxserver-mod-vuetorrent
- persistence:
    vuetorrent:
      enabled: true
      type: emptyDir

Relevant log output
[mod-init] Running Docker Modification Logic
[mod-init] Adding gabe565/linuxserver-mod-vuetorrent to container
[mod-init] Downloading gabe565/linuxserver-mod-vuetorrent from ghcr.io
[mod-init] Installing gabe565/linuxserver-mod-vuetorrent
[mod-init] gabe565/linuxserver-mod-vuetorrent applied to container
[migrations] started
[migrations] no migrations found
usermod: no changes
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    911
User GID:    911
───────────────────────────────────────
Linuxserver.io version: 4.6.6-r0-ls350
Build-date: 2024-09-15T06:53:09+00:00
───────────────────────────────────────

[custom-init] No custom files found, skipping...
WebUI will be started shortly after internal preparations. Please wait...

******** Information ********
To control qBittorrent, access the WebUI at: http://localhost:8080

The WebUI administrator username is: admin
The WebUI administrator password was not set. A temporary password is provided for this session: mytemporarypasswordishere
You should set your own password in program preferences.
Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded!
[ls.io-init] done.

@zozidalom Hmm is there any chance you had typed a different login at some point in the past? Maybe your browser is automatically typing the wrong password. Could you try in an incognito window or with a different browser to verify that's not the issue?

@gabe565 I use Brave as my browser, and I tried using incognito mode, but I'm still experiencing the same issue. I also tried turning brave shields of as I do usually but I am still immediately prompted with "Unauthorized", and not prompted for any kind of basic auth.

https://github.com/linuxserver/docker-qbittorrent/issues/305
https://github.com/linuxserver/docker-qbittorrent/issues/294
Helped me fix the issue. It doesn't like port forwarding using a different external port.


MenuEmbed suggestion/confusion

Hello, can you add an example of MenuEmbed?, because I don't understand the one in README.md

Hi, since that is an example already, what is it that you don't understand about it?

Hi, since that is an example already, what is it that you don't understand about it?

Oh, I've been studying it for a week and now I get it. But can it only be MenuEmbed not with the prompt?

Oh, I've been studying it for a week and now I get it. But can it only be MenuEmbed not with the prompt?

What do you mean not with prompt? Because it's essentially just a wrapper on discord.js's MessageEmbed, where it auto-handles pagination and adding options

What do you mean not with prompt? Because it's essentially just a wrapper on discord.js's MessageEmbed, where it auto-handles pagination and adding options

Yes, I just want to embed it not with the prompt

Yes, I just want to embed it not with the prompt

Unfortunately it's only meant for use with prompts. If you'd like to send an embed with pagination, you'll have to make an API using the methods on it https://github.com/synzen/discord.js-prompts/blob/master/src/MenuEmbed.ts.,

Unfortunately it's only meant for use with prompts. If you'd like to send an embed with pagination, you'll have to make an API using the methods on it https://github.com/synzen/discord.js-prompts/blob/master/src/MenuEmbed.ts.,

Ok, thanks for helping

Ok, thanks for helping


可以把这个做个界面管理工具 可以定时备份吗

可以把这个做个界面管理工具 可以定时备份吗，目前只能是引用dll自己开发吗

没多大必要吧，这个真的是你自己的需求了....

Actually, this is an interesting idea. Somewhere in the future, I plan to do something similar to phpMyAdmin.
However, for automatic backups, you can use Windows services to run a console app that will back up the database in a loop every 24 hours (for example).
If you are working on web development, some web hosting providers do offer a scheduled task feature, such as smarterasp.net. If you are running your own VPS, setting up a scheduled task is even easier. With the scheduled task, Windows can execute a console app or visit a local hosted page to initiate the backup process.

It took me about an afternoon to complete a similar function.
3 | 20230824_0714.sql | 13.52 | 2023-08-24 07:15:12 | Download Delete
4 | 20230824_0657.sql | 13.52 | 2023-08-24 06:58:10 | Download Delete
2 | 20230824_0558.sql | 10.05 | 2023-08-24 05:58:55 | Download Delete
1 | 20230824_0555.sql | 13.52 | 2023-08-24 05:56:42 | Download Delete
So...
That is unnecessary.


model = lp.Detectron2LayoutModel('lp://PrimaLayout/mask_rcnn_R_50_FPN_3x/config') this step raise the error

Can you help me see why this error occurs, thank you very much ！！！

Thanks for asking! The major cause is GFW - I don't think Chinese users could have access to dropbox. Currently the proxy solution is to download the configs and weights manually first (you could find it in model zoos) using a VPN.  In the long term, we will try to cooperate with mirror sits like USTC or Tsinghua Open source mirror to support downloading the weights more conveniently.


fixes missing swagger operation objects

It fixes missing operation objects when multiple methods defined on the same path.

LGTM


(Feature Request) Automatic related sync

A feature where it automatically matches how some manga are related

Yes this can be a nice feature, it can create collections based on realease date.

That would be extremly taxing on the Server to do that with every scanned series and would increase the time komf needs per series significantly.
As it needs to start searching if you even have the related series in you library.
Im strongly against this or that its definetly disabled by default.


Invite me to the GitHub Community Organization

Name
Alexander (0xCUBE)
Discord Username (if applicable)
0xCUBE#0001
Twiiter username (if applicable)
0xCU8E
Additional Context
Hello everyone!
I'm Alex from the USA. I'm a student and love to code and tinker with tech. I am an aspiring computer science major and love playing with website building, homelabs, and server management/sysadmin. I also love contributing to open-source projects and have made a few of my own! I would love to be a part of the collab community to be a part of something that's bigger than myself, to which I can (hopefully 😊) contribute a lot.
Thanks for considering me!

just a note - my discord username discrim (the 4 numbers) might change soon because my nitro will expire. Just wanted to put it out there. The new username will be in my github account when it does happen.

just a note - my discord username discrim (the 4 numbers) might change soon because my nitro will expire. Just wanted to put it out there. The new username will be in my github account when it does happen.

No worries! We don't require the Discord username as a matter of fact, but I see you've joined the server so that's great!


Add version specification

According to this article: https://megamorf.gitlab.io/2020/09/19/access-native-services-on-docker-host-via-host-docker-internal/
The host-gateway option is available since Docker 20.03.
Change is based on this issue: https://github.com/spatie/laravel-ray/issues/102

Thanks!

Thanks!


@conda-forge-admin, please add bot automerge

@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/libdlf-feedstock#3.


fix: pass cookie header in fetch request

:tada: This PR is included in version 1.0.11 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Split transform functions and test stationarity function

The test_stationarity function also contains the transformation function. We could split these functions. The transformation function should be a Class containing all the transformations, while the test_stationarity function would only handle the statistical test.

Added in https://github.com/paulozip/alchemy/commit/f17af4524ca059980295d52b457d21917105bf2e


Day230

Resolves #473.

Pull Request Test Coverage Report for Build 888

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 886:
0.0%

Covered Lines:
5

Relevant Lines:
5

💛  - Coveralls


Fix expected output of an anagram test

It seems that the intent is for passing candidates to be returned unchanged.

I agree with this; seems in line with most languages' tests (at least the ones where I've done the exercise...)
Go is one exception I'm aware of, it always outputs lowercase (like how the json file is before this PR).

Yeah, agreed. Thanks.

Go is one exception I'm aware of, it always outputs lowercase

It will no longer be if https://github.com/exercism/xgo/pull/694.

Okay, after that change. Do we still need "detects anagrams case-insensitively" and "detects anagrams using case-insensitve possible matches"?
         {
             "description": "detects anagrams case-insensitively",
             "subject": "Orchestra",
             "candidates": ["cashregister", "Carthorse", "radishes"],
             "expected": ["Carthorse"]
         },
         {
             "description": "detects anagrams using case-insensitive subject",
             "subject": "Orchestra",
             "candidates": ["cashregister", "carthorse", "radishes"],
             "expected": ["carthorse"]
         },
         {
              "description": "detects anagrams using case-insensitve possible matches",
              "subject": "orchestra",
              "candidates": ["cashregister", "Carthorse", "radishes"],
 -            "expected": ["carthorse"]
 +            "expected": ["Carthorse"]
          },

Do we still need "detects anagrams case-insensitively" and "detects anagrams using case-insensitve possible matches"?

I think I saw a solution (I don't know when I saw it, so I can't find it to link to it) that only accepted capitalised candidates if the subject is also capitalised, so the latter two cases would find that. Don't know how common it is.


Dracula Powerlevel10k theme Oh My Posh

🌱 New Theme
I have made a Dracula Powerlevel10k theme for Oh My Posh.
Dracula Powerlevel10k for Oh My Posh

Hey, that's very cool! ✨
I just sent you an invitation to join the organization.
I also cloned your repository for Dracula's organization, so you can go ahead and delete or archive yours:

Your repository.
New repository.

Thanks for building this! 🎉


double[] gauss ops don't run on sample data

When testing the Ops use case I tried running other filter.gauss signatures.
When running a signature with an sigma array, it goes to double[] (instead of number in the single-sigma variants?) and those then do not work on the input test image (embryos). I am assuming this is an issue with type matching..?

@hinerm what's the error?  The underlying Op uses one sigma per dimension, so you need the length of the sigma list to be (at least) 3 if you're using the embryos test image

It's unfortunate that there is no indication that a sigma for each dimension is needed - I guess a symptom of exposing the underlying ops directly instead of an abstraction that matches ops to the params.
Also, unfortunate that no feedback is given in the UI that the Op failed.

Essentially duplicated by #234

@hinerm There is an already an issue for this in the imagej-ops issue tracker: imagej/imagej-ops#646


Provisioner can't start node with Taints

Hi
Env:
karpenter version: v0.7.3
I have the provisioner with taints config as follows:
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: systemnodes
spec:
  # If omitted, the feature is disabled and nodes will never expire.  If set to less time than it requires for a node
  # to become ready, the node may expire before any pods successfully start.
  ttlSecondsUntilExpired: 2592000 # 30 Days = 60 * 60 * 24 * 30 Seconds;

  # If omitted, the feature is disabled, nodes will never scale down due to low utilization
  ttlSecondsAfterEmpty: 30

  # Provisioned nodes will have these taints
  # Taints may prevent pods from scheduling if they are not tolerated
  taints:
    - key: systemnodes
      effect: NoSchedule

  # Labels are arbitrary key-values that are applied to all nodes
  labels:
    billing-team: my-team

  # Requirements that constrain the parameters of provisioned nodes.
  # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
  # Operators { In, NotIn } are supported to enable including or excluding values
  requirements:
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: ["m5.large", "m5.2xlarge"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
    - key: "kubernetes.io/arch"
      operator: In
      values: ["amd64"]
    - key: "karpenter.sh/capacity-type" # If not included, the webhook for the AWS cloud provider will default to on-demand
      operator: In
      values: ["spot"]

  # Karpenter provides the ability to specify a few additional Kubelet args.
  # These are all optional and provide support for additional customization and use cases.
  # kubeletConfiguration:
  #   clusterDNS: ["<IP_ADDRESS>"]

  # Resource limits constrain the total size of the cluster.
  # Limits prevent Karpenter from creating new instances once the limit is exceeded.
  limits:
    resources:
      cpu: "100"
      memory: 100Gi

  # These fields vary per cloud provider, see your cloud provider specific documentation
  provider:
    subnetSelector:
      karpenter.sh/discovery: demo
    securityGroupSelector:
      karpenter.sh/discovery: demo

This is file test:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: systemnodes
spec:
  replicas: 20 #You can scale up the deployment
  selector:
    matchLabels:
      app: systemnodes
  template:
    metadata:
      labels:
        app: systemnodes
    spec:
      containers:
        - name: systemnodes
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
          resources:
            requests:
              cpu: 1
              memory: 256M
            limits:
              memory: "1G"
              cpu: 2
      nodeSelector:
        kubernetes.io/arch: amd64
        topology.kubernetes.io/zone: ap-southeast-1c
        karpenter.sh/capacity-type: spot

      tolerations:
      - key: "systemnodes"
        operator: "Exists"
        effect: "NoSchedule"

I check kubectl get pod
systemnodes-68b7d7b877-42z7g   0/1     Pending   0          12m
systemnodes-68b7d7b877-7c2kv   0/1     Pending   0          12m
systemnodes-68b7d7b877-7crdp   0/1     Pending   0          12m
systemnodes-68b7d7b877-7zczq   0/1     Pending   0          12m
systemnodes-68b7d7b877-9qplm   0/1     Pending   0          12m
systemnodes-68b7d7b877-dfz6s   0/1     Pending   0          12m
systemnodes-68b7d7b877-dq66k   0/1     Pending   0          12m
systemnodes-68b7d7b877-frnb7   0/1     Pending   0          12m
systemnodes-68b7d7b877-g542x   0/1     Pending   0          12m
systemnodes-68b7d7b877-jhqkv   0/1     Pending   0          12m
systemnodes-68b7d7b877-kw8x5   0/1     Pending   0          12m
systemnodes-68b7d7b877-m7wls   0/1     Pending   0          12m
systemnodes-68b7d7b877-mt589   0/1     Pending   0          12m
systemnodes-68b7d7b877-mvb4s   0/1     Pending   0          12m
systemnodes-68b7d7b877-mzmqn   0/1     Pending   0          12m
systemnodes-68b7d7b877-qjfwr   0/1     Pending   0          12m
systemnodes-68b7d7b877-rklqs   0/1     Pending   0          12m
systemnodes-68b7d7b877-sfxqm   0/1     Pending   0          12m
systemnodes-68b7d7b877-xxqgp   0/1     Pending   0          12m
systemnodes-68b7d7b877-zdmk8   0/1     Pending   0          12m

Provisioner can't start node when using taints
Thank you so much

Hey! Thanks for submitting this issue!  I've just tested your provisioner and systemnodes deployment in Karpenter v0.8.1 and it is working for me.
Are you able to provide the Karpenter controller logs? There should be a log explaining why the pods are not causing a node to provision.  You might also try removing the instance type requirements in your provisioner, just to make sure low capacity isn't causing the provisioning issue since you are using Spot.

Thank you so much @bwagner5
But i has create 2 file provisioner with 1 not taint and 1 taint.
I has the provisioner with not taints config as follows:
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: appnodes
spec:
  ttlSecondsUntilExpired: 2592000
  ttlSecondsAfterEmpty: 30
  labels:
    billing: team-devops
  requirements:
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: ["m5.large", "m5.2xlarge"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
    - key: "karpenter.sh/capacity-type" # Defaults to on-demand
      operator: In
      values: ["spot"] # ["spot", "on-demand"]
  provider:
    subnetSelector:
      karpenter.sh/discovery: demo
    securityGroupSelector:
      karpenter.sh/discovery: demo

Get pods from namespace default
kubectl get pods
NAME                           READY   STATUS    RESTARTS   AGE
systemnodes-68b7d7b877-2f5gp   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-2vj9w   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-486hg   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-8pqtr   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-9vbhs   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-b797n   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-cpc89   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-dfvvp   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-f2hgm   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-jmn5g   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-kt797   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-kwttq   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-lmpqx   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-nndgt   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-tct75   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-vwqhc   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-w752r   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-wj22l   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-wwnvk   0/1     Pending   0          6m38s
systemnodes-68b7d7b877-znx9s   0/1     Pending   0          6m38s

And kubectl describe pods
Name:           systemnodes-68b7d7b877-vwqhc
Namespace:      default
Priority:       0
Node:           <none>
Labels:         app=systemnodes
                pod-template-hash=68b7d7b877
Annotations:    kubernetes.io/psp: eks.privileged
Status:         Pending
IP:
IPs:            <none>
Controlled By:  ReplicaSet/systemnodes-68b7d7b877
Containers:
  systemnodes:
    Image:      public.ecr.aws/eks-distro/kubernetes/pause:3.2
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:     2
      memory:  1G
    Requests:
      cpu:        1
      memory:     256M
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vzv55 (ro)
Conditions:
  Type           Status
  PodScheduled   False
Volumes:
  kube-api-access-vzv55:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              karpenter.sh/capacity-type=spot
                             kubernetes.io/arch=amd64
                             topology.kubernetes.io/zone=ap-southeast-1c
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
                             systemnodes:NoSchedule op=Exists
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  29s (x13 over 13m)  default-scheduler  0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector.

Then i check logs of Karpenter controller:
2022-04-12T02:31:49.223Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:31:49.223Z	INFO	controller.provisioning	Waiting for unschedulable pods	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:31:55.225Z	INFO	controller.provisioning	Batched 20 pods in 1.001765225s	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:31:55.610Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:31:55.624Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:31:55.644Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:31:55.644Z	INFO	controller.provisioning	Waiting for unschedulable pods	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:01.646Z	INFO	controller.provisioning	Batched 20 pods in 1.0014693s	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:02.023Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:02.040Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:02.050Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:02.050Z	INFO	controller.provisioning	Waiting for unschedulable pods	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:08.053Z	INFO	controller.provisioning	Batched 20 pods in 1.002048178s	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:08.433Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:08.449Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:08.456Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:08.456Z	INFO	controller.provisioning	Waiting for unschedulable pods	{"commit": "8280611", "provisioner": "appnodes"}
kgp2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-jmn5g"}
2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-9vbhs"}
2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-8pqtr"}
2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-tct75"}
2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-f2hgm"}
2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-b797n"}
2022-04-12T02:32:13.457Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-486hg"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-lmpqx"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-kt797"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-2f5gp"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-dfvvp"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-znx9s"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-vwqhc"}
2022-04-12T02:32:13.458Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-w752r"}
2022-04-12T02:32:13.459Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-kwttq"}
2022-04-12T02:32:13.459Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-wwnvk"}
2022-04-12T02:32:13.459Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-cpc89"}
2022-04-12T02:32:13.459Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-wj22l"}
2022-04-12T02:32:13.459Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-nndgt"}
2022-04-12T02:32:13.459Z	DEBUG	controller.selection	Relaxing soft constraints for pod since it previously failed to schedule, adding: toleration for PreferNoSchedule taints	{"commit": "8280611", "pod": "default/systemnodes-68b7d7b877-2vj9w"}
2022-04-12T02:32:14.460Z	INFO	controller.provisioning	Batched 20 pods in 1.002980789s	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:14.823Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}
2022-04-12T02:32:14.850Z	ERROR	controller.provisioning	Launching node, creating cloud provider machine, with fleet error(s), UnfulfillableCapacity: Unable to fulfill capacity due to your request configuration. Please adjust your request and try again.	{"commit": "8280611", "provisioner": "appnodes"}

Why are my pods scheduled on appnodes, but do my pods with taint, it have to provisioner on systemnodes?

Hey, I replicated your setup as well and was able to bring up pods and nodes only by relaxing the constraints of the instance types. I checked the nodes and it has the taints. It looks like your controller logs show that you're running into the same problem.
The logs also show that it added the PreferNoSchedule Toleration into your pods to enable it to schedule to some nodes, which happens if no provisioners match the node, which is running as expected.
Can you scale the systemnodes pods before the appnodes pods and see if they schedule when spot capacity becomes available?

It works well from me either, I think the problem is from your nodeSelector  which specifies the Pod must be assigned on node with topology.kubernetes.io/zone: ap-southeast-1c and it's not sure the Spot instance is available for request in that subnet.
In practice, I think we should set the subnetSelector to pick subnet in private VPC and no need to specify the zones for it, so Spot request has more options to create nodes and Pod is quickly up


Setting parameters Command protocol PI30

Hi, I have installed your configuration and I read everything correctly but I would also like to use the following commands (or all if possible) to modify the parameters from home assistant:

MCHGC
MNCHGC
MUCHGC
PCVV
PBFT
can anything be done?
In the yaml I tried to use output as it says in the official guide(https://esphome.io/components/pipsolar.html) but it doesn't work.
My yaml:
my yaml.txt

My inverter is: ISolar SML lll 5.5 KW
Thank you.

Me too.


[release-branch.go1.19] cmd/compile: use absolute file name in isCgo check

For https://github.com/golang/go/issues/23672
Updates https://github.com/golang/go/issues/63211
Fixes https://github.com/golang/go/issues/63213
Fixes https://github.com/advisories/GHSA-679v-hh23-h5jh
Cherry-pick https://github.com/golang/go/commit/31d5b604ac0adb58aec4870ac1b974c08312fd49 from release-branch.go1.20.

Does it mean the fix won't be backported to 1.19?


refactored READMEs moved most to docs

The workflows should now run.

Fixing workflows will be done in another PR


test: popover tests

There is a lot of warnings form Testing Library in console https://github.com/yandex-cloud/uikit/runs/7788152251?check_suite_focus=true#step:5:10

There is a lot of warnings form Testing Library in console https://github.com/yandex-cloud/uikit/runs/7788152251?check_suite_focus=true#step:5:10

The problem appears when rendering a tooltip inside it and simply wrapping it in act or applying the timers functionality will not help. There is an option to mock the tooltip for the test, but this is not the best solution, since the tooltip is the basis of the popover.


simulator slider on firefox

The simulator sliders (temperature, lightlevel, etc) don't work as smooth in firefox as they do in chrome. It happens often in firefox that you manage to drag the actual picture instead of that the slider moves. And then when you release, the slider starts moving and is "stuck" to your mousemovements because you have already released..
A bit hard to put in words, try it yourself and you will see. It's really frustrating, and it is the sole reason why I usually make people use chrome instead of firefox in microbit workshops.

@nielsswinkels if you could record an animated gif of the issue, that would help a lot.

@pelikhan I think @nielsswinkels is referring to the simulator sliders, not the Blockly sliders.

yes the simulator, where you simulate changing temperature and light levels. It's a bit tricky to record it because you need to know when I click and release the mouse..

Oh those...

I can still repro this.

This is in the beta, I can still manage to drag the image of the circle instead of changing the slider value.

Should this be fixed in the beta now? I can still reproduce it:

@caitlin-hennessy maybe this isnt just a user select issue?

We weren't able to repro this anymore on Firefox for Mac or Windows. @nielsswinkels please check again with the latest /beta. Make sure you're running Makecode version 0.12.125. (Check in Settings -> About).
If this still repro's for you, please share what version of Firefox you are running. Thanks!


Update Purchases text

Fix typos. Fixed Huawei links. Removed some part on links (e.g. languages data). Reworded a note

@EugeneZmeuk you are the last one who edited that file. Could you please give my edits a look?


Hotfix/bug 13252

This change is

Current coverage is 58.31% (diff: 29.23%)

No coverage report found for master at 56d4bcb.

Powered by Codecov. Last update 56d4bcb...7b1009f

Reviewed 13 of 14 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Updating branch feature/devflow with new master README

Can't do it this way - I want to cherry-pick which commits to include in the pull request, and it looks like that's not possible this way. Instead, I need to make a temporary branch from master, change it to match the commits I want to move to feature/devflow, and then merge it with feature/devflow.


Add InstrumentedExecutorService for monitoring executor services

What changes are proposed in this pull request?
This allows better monitoring of thread pool executors using the InstrumentedThreadPool executor from https://github.com/dropwizard/metrics. It adds instrumentation for the thread pool executors in DefaultFileSystemMaster for the meta data sync executors.
Why are the changes needed?
This helps monitor the queues and executors in case of high load and memory usage.
Does this PR introduce any user facing changes?
New metrics for the thread pool executors in DefaultFileSystemMaster for the meta data sync executors. A warning log is printed every 5 seconds with the number of active tasks (running or queued) if the number is above 1000. (Should this be configurable?)

@tcrain could you highlight the warning messages in the PR description, as that is user-facing, important for diagnostics.

Ok I added that, should those numbers be configurable via property key?

due to the potentially non trivial cost of the instrumentedExecutorService, let;s put it behind a flag and make the warning messages configurable. It is a general utility, so i can imagine we use this for all other executors as well.

Ok now the logging and the instrumentation is configurable by property key and disabled by default.

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.7 please

alluxio-bot, cherry-pick this to branch-2.7 please

alluxio-bot, cherry-pick this to branch-2.7 please

alluxio-bot, cherry-pick this to branch-2.8 please

alluxio-bot, cherry-pick this to branch-2.8 please


Correct status displayed on graph during ongoing git repository opera…

…tions

When repository state is APPLYING (e.g. after git am) you can freely checkout other branches, but the ongoing operation is not bound to one branch, rather it can always be applied on what is HEAD at the moment. This is reflected in the change.


Fixes #262 - Integration testing more stable in maven.

Forces maven-failsafe-plugin in parent (with version)
Moves jetty9-compact-base tests back into src/test/java
Renames integration tests from *Test.java to *IT.java to
better conform to new recommendations from maven-failsafe-plugin
(convention over configuration!)

This PR isn't sane (yet), a followup commit (to correct checkstyle warnings) is due for this PR.

Google Style Guide is incompatible with maven-failsafe-plugin.

/home/joakim/code/jetty/appengine-java-vm-runtime/jetty9-compat-base/src/test/java/com/google/apphosting/vmruntime/jetty9/VmRuntimeJettyAuthIT.java:30: error: Abbreviation in name must contain no more than '1' capital letters.

We'll need an exception.

@aozarov do you want me to alter the Checkstyle xml?

@aozarov do you want me to alter the Checkstyle xml?

Please do. it should be fine to have an IT suffix for integration tests and exempt it from checkstyle.

@aozarov why didn't the google-java-format-1.0-all-deps.jar fix these import issues?

Ah, import management is currently broken in the google-java-format-1.0-all-deps.jar
Also, looks like there's a googleformat-maven-plugin in existence (maintained by @talios)


3bot deployer: eternal loading animation after last step

When trying to deploy a 3bot using the deployer (on testnet):

Reserved for 1 day
Paid in FreeTFT
Payment was successful
Pressed download button on wireguard config
Saved wireguard config, and enabled the wireguard interface on my laptop
A message popped up on the deployer about a request timeout. Pressed ok on the message box
Press the next button on the wireguard config screen
Text is replaced with a loading spinner, and a loading bar appears at the top of the chatbox
Page keeps on showing these loading spinners, nothing really seems to happen

A message popped up on the deployer about a request timeout. Pressed ok on the message box

I think the server is being updated at this time, this is the only time this message can appear.

3bot deployment is working fine and setup done successfully