@vanilla-extract/integration compiler generate "border" at ci envrionment

Describe the bug
We are using vanilla-extract create a css component library.
With vitest framework, And The snapshot generated locally is correct.
But in the ci environment, there will be more “border” attributes

But the button css doesn't has border props

Reproduction
https://github.com/idealjs/camphora/actions/runs/5847174374/job/15853163192
System Info
Github ci

Used Package Manager
yarn
Logs
RUN  v0.34.1 /home/runner/work/camphora/camphora/packages/camphora-styled

 ❯ src/__test__/snapshot.test.ts  (1 test | 1 failed) 1007ms
   ❯ src/__test__/snapshot.test.ts > button
     → Snapshot `button 2` mismatched

⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯

 FAIL  src/__test__/snapshot.test.ts > button
Error: Snapshot `button 2` mismatched

- Expected
+ Received

  ".button_button__1ph4cad6 {
    cursor: pointer;
    display: inline-flex;
    flex-shrink: 0;
    align-items: center;
    justify-content: center;
    text-align: center;
    height: 48px;
    min-height: 48px;
    padding: 0px 16px 0px 16px;
    border-radius: var(--rounded-btn__92wzfbr);
    box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
    transition: background-color 0.2s ease-in-out;
+   border: none;
  }
  .button_button__1ph4cad6:active, .button_button__1ph4cad6.button_buttonActive__1ph4cad0 {
    transform: scale(0.95);
  }
  .button_button__1ph4cad6.button_buttonPrimary__1ph4cad1 {
    background-color: var(--colors-primary-bg__92wzfb4);
    color: var(--colors-primary-content__92wzfb6);
  }
  .button_button__1ph4cad6.button_buttonPrimary__1ph4cad1:hover {
    background-color: var(--colors-primary-focus__92wzfb5);
  }
  .button_button__1ph4cad6.button_buttonNeutral__1ph4cad2 {
    background-color: var(--colors-neutral-bg__92wzfbd);
    color: var(--colors-neutral-content__92wzfbf);
  }
  .button_button__1ph4cad6.button_buttonNeutral__1ph4cad2:hover {
    background-color: var(--colors-neutral-focus__92wzfbe);
  }
  .button_button__1ph4cad6.button_buttonSecondary__1ph4cad3 {
    background-color: var(--colors-secondary-bg__92wzfb7);
    color: var(--colors-secondary-content__92wzfb9);
  }
  .button_button__1ph4cad6.button_buttonSecondary__1ph4cad3:hover {
    background-color: var(--colors-secondary-focus__92wzfb8);
  }
  .button_button__1ph4cad6.button_buttonAccent__1ph4cad4 {
    background-color: var(--colors-accent-bg__92wzfba);
    color: var(--colors-accent-content__92wzfbc);
  }
  .button_button__1ph4cad6.button_buttonAccent__1ph4cad4:hover {
    background-color: var(--colors-accent-focus__92wzfbb);
  }
  .button_button__1ph4cad6.button_buttonGhost__1ph4cad5 {
    background-color: transparent;
    color: currentcolor;
  }
  .button_button__1ph4cad6.button_buttonGhost__1ph4cad5:hover {
    background-color: color-mix(in srgb, var(--colors-base-content__92wzfb3) var(--opacity-btn__92wzfbo), #fff0);
  }"

 ❯ src/__test__/snapshot.test.ts:24:15
     22|     export var button = 'button_button__1ph4cad6';"
     23|   `);
     24|   expect(css).toMatchInlineSnapshot(`
       |               ^
     25|     ".button_button__1ph4cad6 {
     26|       cursor: pointer;

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯

  Snapshots  1 failed
 Test Files  1 failed (1)
      Tests  1 failed (1)
   Start at  12:05:51
   Duration  1.52s (transform 72ms, setup 0ms, collect 217ms, tests 1.01s, environment 0ms, prepare 99ms)

Done in 2s 279ms

Validations

[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible example of the bug.

@cqh963852 Looking at the button.css.ts file now, I see there is a border: none style. Maybe your local snapshot was generated before this PR was merged?
More generally, what is the intention of this test? You're basically testing that the Vanilla Extract compiler works correctly, separate from whatever integration you're using (e.g. vite). There are already tests for this - they are inside the Vanilla Extract repo. You, as a consumer of the integration, shouldn't have to worry that the integration works correctly - that's the job of the maintainers of the package.

@askoufis
Thanks a lot for help.

More generally though, what is the intention of this test?

I added this test to avoid breaking changes that would cause visual changes.
After modifying the related component style, we need to check the corresponding snapshot.
Currently, it is only a code snapshot. In the future. We will prepare to add an image snapshot.
Do you have testing suggestions for component libraries?

Image snapshots will be much more useful in the long term if you want to prevent visual regressions. CSS snapshots don't really help to spot visual changes, you're really just testing that the styles you wrote generate the correct CSS (again, we're already testing this for you). You don't even have components yet, so you're not even testing that the components are correctly using the CSS at all.
Also, the hashes of the classnames will change, so that's just more time spent updating snapshots that aren't really testing anything.


URGENT - iTunes Store Payload Issue related with Localization

I wanted to publish my app and uploaded a binary to testflight but got this email from iTunes store.
Dear developer,

We have discovered one or more issues with your recent delivery for "XXX(app name)". Your delivery was successful, but you may wish to correct the following issues in your next delivery:

Unrecognized Locale -
The directory located at ( 'Payload/XXX.app/Frameworks/DKImagePickerController.framework/DKImagePickerController.bundle/DK-nb-NO.lproj' ) has an unrecognized locale name. Refer to the Language and Locale Designations guide for more information on naming your language-specific directories.

After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.

Regards,

The App Store team

Would you please fix this asap?

Fixed in https://github.com/zhangao0086/DKImagePickerController/pull/330

Thanks!!!


fixing cred_preview issue in issuing credential offer

In Issuing credential offer for Acme, cred_preview variable is missing and due to this acme agent will throw " Acme | Error during POST /issue-credential/send-offer: 422, message='Unprocessable Entity', url=URL('http://<IP_ADDRESS>:8041/issue-credential/send-offer')"

So to fix this issue, I have added the cred_preiew object and add that property in offer_request object.

Codecov Report

Merging #549 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #549   +/-   ##
=======================================
  Coverage   96.39%   96.39%
=======================================
  Files         240      240
  Lines       12575    12575
=======================================
  Hits        12122    12122
  Misses        453      453

I can take this tomorrow morning

@spsingh559 --- note the problem with the DCO - the signing of the commit (using "-s" on the commit command, if you are using command line git).  Can you look at the "details" like beside that and see if you can fix it?  You may have to do another PR if this cannot be fixed in this PR.  Sorry about that -- a bump in the road on the first commit to a Hyperledger Repo.
If you have trouble, we can connect on RocketChat so I know how you are using git and then what you need to do.
@ianco - can you please review the change?
Thanks!

Thanks Stephen, I have followed the step mentioned here in DCO Details https://github.com/hyperledger/aries-cloudagent-python/pull/549/checks?check_run_id=752742907
Shall I create a new pull request and repeat the process again.

109 files changed? Surely it must be simpler to start from master on a new PR?

Signed and repackaged as https://github.com/hyperledger/aries-cloudagent-python/pull/550: thanks, good catch


Release Google.Cloud.Billing.Budgets.V1 version 2.6.0

Changes in this release:
New features

Add IServiceCollection extension methods for client registration where an IServiceProvider is required. (commit 022fab2)

Created release for Google.Cloud.Billing.Budgets.V1-2.6.0


Use named structs for pallet event

Signed-off-by: koushiro<EMAIL_ADDRESS>

Modifying events is considered a breaking change. When you have a moment, can you describe the motivation for it or the use case/s where this change adds value?

For the chain itself, I don't think this is a breaking change, because the scale encoding/decoding result of the pallet event are the same before and after the modification. But for 3rd party apps, I haven't thought much yet.
The reason why I changed this is because the upstream pallets seem to have already made this change

But for 3rd party apps, I haven't thought much yet.

It shouldn't be a breaking change for them either. They can continue to use the old type definitions and that'll work without problems.
I don't have any objections merging this -- it just makes the code slightly more descriptive, which is good. I'll wait till tomorrow before merging though just in case if there're objections / I missed anything.

Thank you @koushiro and @sorpaas. Indeed I was concerned about 3rd party apps and if this change is not an issue for them then the PR lgtm.


Missing pixel when using draw_rect

Godot version:
3.2-dev (https://github.com/godotengine/godot/commit/5ffae0d299aa799c7787e01f3cfe5e377b78a411)
OS/device including version:
Windows 10 64-bit
Issue description:
A small issue, but an issue nevertheless. When drawing with the draw_rect function, there is a missing pixel in the lower left corner. If using fill, the bug doesn't introduce itself. This happens on both GLES3 and GLES2.

Steps to reproduce:
Just put this script to a Node2D:
extends Node2D

func _draw():
	draw_rect(Rect2(1, 1, 100, 100), Color(0.5, 0.8, 0.5), false)

Minimal reproduction project:
DrawRectBug.zip

Is it always missing if you draw that rectangle at different positions, and with decimal coordinates?

I can reproduce this on commit https://github.com/godotengine/godot/commit/a226d63f6815836284f947ccc56b688448381f84. Note that the missing pixel will not always be in the bottom-left corner; it depends on the rectangle's position (see demo project below).
Demo project: DrawRectBug_with_anim.zip

A half pixel offser is required to make this work: draw_rect(Rect2(0.5, 0.5, 100.5, 100.5), Color(0.5, 0.8, 0.5), false)
(though, pixel snap has to be disabled)
Note that this only applies to unfilled rectangles, as mentioned in the original post.

Is it always missing if you draw that rectangle at different positions, and with decimal coordinates?

If I'm using integer coordinates, then it's always in the bottom left corner. If I'm using decimal coordinates, then it shifts between the bottom left and bottom right corner.
Tested with this script (and tried changing the increment to 0.5, when testing the decimal coordinates):
extends Node2D

var pos_x := 0.0
var pos_y := 0.0
var increment := 1

func _draw():
	draw_rect(Rect2(pos_x, pos_y, 100, 100), Color(0.5, 0.8, 0.5), false)

func _process(delta):
	if Input.is_action_pressed("ui_up"):
		pos_y -= increment
	elif Input.is_action_pressed("ui_down"):
		pos_y += increment

	if Input.is_action_pressed("ui_left"):
		pos_x -= increment
	elif Input.is_action_pressed("ui_right"):
		pos_x += increment

	update()

Anti-aliased version:
draw_rect(Rect2(1, 1, 100, 100), Color(0.5, 0.8, 0.5), false, 1.0, true)

For the record, the width and antialiased draw_rect() parameters were added in #30461.


Bootstrap 4

Has an alpha version of Bootstrap 4. It would be great so she stood their boxes.
http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/

@jumper423  https://github.com/yiisoft/yii2-bootstrap/issues/77


chore : update packages

update packages with newest version

Please fix merge conflicts and do not commit the .flutter-plugins files, those should be generated on the user end.

removed


ASYNC API: "Failure establishing SSH session, handshake failed" and malloc

Hi everyone!
I'm using NMSSH for an App, which is polling information, like for example CPU usage, from a server every 5 sec in the background, in order to show status updates in the App.
Example: Executing mpstat to fetch the latest CPU usage.
The ASYNC API works way better for this use case as the standard NMSSH Library but after a period of time I'm receiving this error message in my xCode debug console:

NMSSH: Failure establishing SSH session, handshake failed

Followed immediately by a malloc in line of the session connection (find below):

malloc: *** error for object 0x610000c30a80: Invalid pointer dequeued from free list
*** set a breakpoint in malloc_error_break to debug

I don't know, what kind of information are needed in case of mallocs but at least here is a snipped of code I'm using:
self.session = [[NMSSHSession alloc] initWithHost:self.sHostname port:self.iPort andUsername:self.sUsername];

    [self.session connect:^(NSError *error) {      // The malloc last stack trace points to this line
        if (error) {
            if (NULL != completionHandler)
                completionHandler(error);
        }
        else if (!self.session.isConnected) {
            if (NULL != completionHandler)
                completionHandler([NSError errorWithDomain:@"CONNECTION ERROR" code:8000 userInfo:nil]);
        }
        else
        {
            [self.session authenticateByPassword:self.sPassword success:^{

                [self.session.channel startShell:^{
                    if (NULL != completionHandler) {
                        completionHandler(nil);
                    }
                } failure:^(NSError *error) {
                    if (NULL != completionHandler) {
                        completionHandler(error);
                    }
                }];
            } failure:^(NSError *error) {
                if (NULL != completionHandler) {
                    completionHandler(error);
                }
            }];
        }
    }];

I'd be very thankful for any hint or workaround!
Cheers!

I am also running into this problem in High Sierra. What OS are you using?

Use


Installation of headless version crashes with "ModuleNotFoundError: No module named 'skbuild'"

Expected behaviour
Install the library into container like a breeze.
Actual behaviour
Errors out with "ModuleNotFoundError: No module named 'skbuild'" even after upgrading pip to latest available version.
Steps to reproduce

Ubuntu 20.04
pip 20.2.4
Docker version 19.03.13, build 4484c46d9d
docker-compose version 1.25.0
Python 3.7.2-alpine
opencv-python-headless v. <IP_ADDRESS>

I've seen topics on the Internet where upgrading pip usually solved the problem. Not in my case though.
I've tried to install opencv-contrib-python-headless instead but got: Could not find a version that satisfies the requirement. Installing the library for Docker has become quite a mission.

Alpine Linux is not supported by the manylinux standard. Alpine is based on musl C library and manylinux requires a GNU/Linux system with glibc. Hacky workarounds can be found from here: https://github.com/pypa/pip/issues/3969
You did not post the full error output, but the I believe the error comes from cmake and not from opencv-python.
opencv-contrib-python-headless throws that error because it seems that I have hit the PyPI file size limit so some of the source distributions haven't been uploaded properly to PyPI.

Bare bones Alpine version was the catch here yeah. I switched to slim and all was OK. Closing this with thanks.


Travis: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.18' not found

First of: Thanks for this great work. It makes it soo much faster to setup cross compiled and general auto-publishing with Rust! Thanks so much.
Coming to the problem. Some of our dependencies, somewhere deeper down depend on the backtrace and that doesn't compile in the travis setup :( . I've already tried installing other libc6 bindings but I can't find any way to fix this.
   Compiling backtrace v0.3.0

Build failed, waiting for other jobs to finish...

error: failed to run custom build command for `backtrace v0.3.0`

process didn't exit successfully: `/target/release/build/backtrace-e882241ff52c7727/build-script-build` (exit code: 1)

--- stderr

/target/release/build/backtrace-e882241ff52c7727/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.18' not found (required by /target/release/build/backtrace-e882241ff52c7727/build-script-build)

Full Travis log and the Travis config file used to come to this. I appreciate any input/hints/ideas!

Try removing dist: trusty from your .travis.yml. Maybe that causes other things to fail, but it's worth a try. :)

@johannhof been there - same issue.

I think I found "the problem". So cross uses docker images internally to build for the targets, right? Well, it looks like x86_64-unknown-linux-gnu only supports libc 2.15.
Which is reported there accordingly, so I'll close this here.


How to Sign the assembly with a strong name

without a strong name I get a warning message from Defender
Can someone please help me

Thanks for using FlashCap!
FlashCap does not have Strong name applied, but if you need:

Clone the repository and build the project yourself. At that time, modify the project slightly to apply the Strong name.
Extract the assemblies you need from the NuGet package and apply the Strong name directly.  Apparently this can't be done....

I understand that these methods are tedious ¯\_(ツ)_/¯
However, I do not intend to apply strong name to FlashCap at this time. When considered in the context of security assurance, we view the application of strong names as a security technique of the past. If you want to ensure security, I recommend using code signing certificates instead of strong names:

Reference: https://learn.microsoft.com/en-us/dotnet/standard/assembly/security-considerations

If you are building a program as an in-house system and it is a problem with your in-house managed Defender, I would suggest that you share with your team that such a policy is nonsense. On the other hand, if it is simply a problem that is occurring with an application that you are personally building, you could, for example, add the build directory to Defender's exclusion rules.
(If Defender is referring to Windows Defender, there may be some other factor, since the problem is not occurring in my environment.)
I have some other personal questions for myself:

Handling of signature keys, as you can see if you look for OSS projects that apply Strong name.
As you can see when you look for projects that apply Strong name to OSS projects, private keys that should be covered up are often placed in the OSS project and published together.
This technology is really ridiculous and shows that Strong name technology does not make any sense other than providing IDs.
Maintaining CI is a pain; CI automates the build, but the bottleneck here is the management of the private key used to apply the Strong name. As mentioned above, this is one of the reasons why many OSS projects expose private keys.

For projects that rely on a large number of external assemblies, it is easy to have builds not pass due to mismatches between dependent versions. This would seem to work to ensure full compatibility. However, in modern .NET development, there are large numbers of assemblies that are resolved by NuGet.
While many OSS are tolerant of version mismatches because they are maintained backward compatibility of the assembly's public interfaces. When an assembly with Strong name applied exists, the strictness of the version conformity causes a version mismatch error that is difficult for humans to understand. I have spent with this issue for a long time and have made the choice to abandon Strong name technology.

I forgot to mention that Microsoft has recently started applying digital signatures automatically to packages published from nuget.org. This does not mean that they will digitally sign the assembly, but they want it to serve as a source for us to verify the origin of the package.

It looks like there will probably be no additional information, so I will close it once. If there are any problems, please reopen.


Fixing a bunch of codacy warning

Couple of questions: I've received more emails from codacy lately. Did something change in the codacy setup?

I had to reinstall the codacy hook as they have changed things on their end. That could have caused the changes.

Do you know if there's an option to check pull requests from forked repos as well? I think some of these have snuck in from my changes.

I don't know that, sorry.

Do you know if there's an option to check pull requests from forked repos as well? I think some of these have snuck in from my changes.

I don't know that, sorry.

Update: you might be able to separately integrate your repository with codacy.

Do you know if there's an option to check pull requests from forked repos as well? I think some of these have snuck in from my changes.

I don't know that, sorry.

Update: you might be able to separately integrate your repository with codacy.

No worries. Yes, I can definitely do that. That'll at least work for my PRs.

@msimberg I think this is good to go now.


Log message "Receiving not possible, socket not valid."

On Windows one may get the message
MDDUDPSocket.h: Receiving not possible, socket not valid.

although everything seems to work fine.

Is this reproducible?

Solution is mentioned here: https://github.com/modelica-3rdparty/Modelica_DeviceDrivers/issues/364#issuecomment-1291616582


InfoPath 2013 for Office 365 not in Add-ODTProductToAdd

Add-ODTProductToAdd ist not able to add InfoPathRetail

Issue has been resolved.  Thank you for your feedback.


Improvements to the Knock Down module

When merged this pull request will:

Improve the Knock Down module.

Previous version of the module is actually probably broken FYI.


Build staging images for KMM

Kubernetes guide: https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io#creating-staging-repos

[x] Create the staging repo for KMM images
[x] Enable automatic builds

PR for the CloudBuild config: https://github.com/kubernetes-sigs/kernel-module-management/pull/56
PR for the postsubmit job: https://github.com/kubernetes/test-infra/pull/27461

I think that if you write Fixes <issue link> on a PR (comment or description) it will autoclose the issue when the PR is merged.
FYI @qbarrand

Slack thread for the bucket creation: https://kubernetes.slack.com/archives/CCK68P2Q2/p1663659562229129

Bucket creation is now complete ✅
Builds are still failing because Prow clones the git repo without the .git directory: https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/post-kernel-module-management-push-images/1572475993145217024#1:build-log.txt%3A88-89
Opened a Slack thread in #sig-testing.

More work needed to include the .git directory in build sources:

Ignore the default .gcloudignore rule for .git: https://github.com/kubernetes-sigs/kernel-module-management/pull/92
Add a command-line flag in the postsubmit job: https://github.com/kubernetes/test-infra/pull/27650


[FLINK-24706][rpc] Forward deserialization errors to returned future

Fixes an issue where issues during the deserialization of RPC messages were silently ignored. We now forward the error to the returned future instead.
@tillrohrmann Could you take a look?

@flinkbot run azure

hmm...the TaskManagerProcessFailureBatchRecoveryITCase is failing pretty reliably now. I'm wondering if this issue was masking another failure as well...

That test failure is driving me crazy.
With the original code the test passes.
            resultFuture.whenComplete(
                    (resultValue, failure) -> {
                        if (failure != null) {
                            completableFuture.completeExceptionally(
                                    resolveTimeoutException(
                                            failure, callStackCapture, address, rpcInvocation));
                        } else {
                            completableFuture.complete(
                                    deserializeValueIfNeeded(resultValue, method));
                        }
                    });

If I move the deserialization into a separate thenApply then it fails.
            resultFuture
                    .thenApply(resultValue -> deserializeValueIfNeeded(resultValue, method))
                    .whenComplete(
                            (resultValue, failure) -> {
                                if (failure != null) {
                                    completableFuture.completeExceptionally(
                                            resolveTimeoutException(
                                                    failure,
                                                    callStackCapture,
                                                    address,
                                                    rpcInvocation));
                                } else {
                                    completableFuture.complete(resultValue);
                                }
                            });

It may be that the test is simply not stable.
What could be happening is that the jobs fails once because the TM loss is noticed by another TM, and then fails again when the JM later attempts to deploy a task to the lost TM.
It's suspicious how consistently the test failed when I switched between the PR and current master, but I also ran into the issue once without any changes...

@flinkbot run azure

From the logs of the failed test run it looks as if we aren't able to detect the dead TM via the lost heartbeats that should be reported to the dead letter queue. From the logs it also looks as if we aren't experiencing a long processing gap which can usually explain a situation like this.

How long does it actually take for Akka to consider something to be unreachable?
It takes quite a while for this to show up:
441053 [flink-akka.actor.default-dispatcher-23] WARN  akka.remote.transport.netty.NettyTransport [] - Remote connection to [null] failed with java.net.ConnectException: Connection refused: no further information: /<IP_ADDRESS>:58498
441056 [flink-akka.actor.default-dispatcher-23] WARN  akka.remote.ReliableDeliverySupervisor [] - Association with remote system [akka.tcp://flink@<IP_ADDRESS>:58498] has failed, address is now gated for [50] ms. Reason: [Association failed with [akka.tcp://flink@<IP_ADDRESS>:58498]] Caused by: [java.net.ConnectException: Connection refused: no further information: /<IP_ADDRESS>:58498]

to show up, and after that we immediately throw RecipientUnreachableExceptions.

So yeah, increasing the restart delay to ~5 seconds would probably do the trick.

I don't know exactly how fast Akka can detect it. I would assume that this can happen quite quickly once the TCP connection is terminated.

This has never been a problem though.

Isn't that because previously we still waited for the heartbeat to time out (10 seconds in this test)?

Maybe. You could enable debug logs and check whether we send heartbeat requests after the TM died. If these requests are not failed, then it is most likely because Akka hasn't detected that the connection is dead yet.

The advantage of increasing the restart attempts instead of the delay is that the test will on average run faster. With the increased delay, the execution of the test will take at least as much longer as you've increased the delay.

I don't have a strong opinion on this. A single restart results in cleaner logs.
If we're aiming to do at most 1-2 restarts then the difference will be negligible either way (+-2s)🤷 The test already needs 30-50 seconds.

Fair enough, then lets go with a single restart and an extended delay.


travis: update osx image

It seems that the default OSX image on travis is having some security
issues, causing builds to fail. So let's try to upgrade the OSX image to
the latest non-beta one, so builds will hopefully work again.

This is just a test to see if this would solve what's blocking #1112.
The right move might instead be to upgrade python or SSL using brew before running sudo easy_install pip. But let's see if this helps first.


Using admissionWebHooks.caBundle causes templating errors

Checks

[X] I've already read https://github.com/actions-runner-controller/actions-runner-controller/blob/master/TROUBLESHOOTING.md and I'm sure my issue is not covered in the troubleshooting guide.
[X] I'm not using a custom entrypoint in my runner image

Controller Version
0.26.0
Helm Chart Version
0.21.1
CertManager Version
1.8.2
Deployment Method
Helm
cert-manager installation
I have cert manager installed but it is not used for my case. I was running without cert manager per the docs and providing a self signed cert.
Checks

[X] This isn't a question or user support case (For Q&A and community support, go to Discussions. It might also be a good idea to contract with any of contributors and maintainers if your business is so critical and therefore you need priority support
[X] I've read releasenotes before submitting this issue and I'm sure it's not due to any recently-introduced backward-incompatible changes
[X] My actions-runner-controller version (v0.x.y) does support the feature
[X] I've already upgraded ARC (including the CRDs, see charts/actions-runner-controller/docs/UPGRADING.md for details) to the latest and it didn't fix the issue
[X] I've migrated to the workflow job webhook event (if you using webhook driven scaling)

Resource Definitions
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: repo-runner
spec:
  replicas: 1
  template:
    spec:
      repository: alexgQQ/selfhost-github-actions
      dockerEnabled: false

To Reproduce
1. Follow the setup [here](https://github.com/actions-runner-controller/actions-runner-controller/blob/master/docs/detailed-docs.md#using-custom-certificates)
2. Try to render the helm template with the ca bundle config

helm template --debug \
  --set=certManagerEnabled=false \
  --set=admissionWebHooks.caBundle=${CA_BUNDLE} \
  --set=authSecret.create=true \
  --set=authSecret.github_token="DEFINITLEYNOTATOKEN" \
  --wait actions-runner-controller actions-runner-controller/actions-runner-controller

Receive parsing error to the tune of:

Error: YAML parse error on actions-runner-controller/templates/webhook_configs.yaml: error converting YAML to JSON: yaml: line 33: could not find expected ':'

### Describe the bug

I was doing some proof of concept related work and tried to run through the setup for running ARC without cert-manager and using a custom cert bundle. Following the [docs](https://github.com/actions-runner-controller/actions-runner-controller/blob/master/docs/detailed-docs.md#using-custom-certificates) returned some templating/parsing errors when trying to deploy. Specifically the provided value is not quoted properly in some sections of the chart and causes the failure.

### Describe the expected behavior

The `caBundle` config should be valid syntax in the rendered chart and the controller should use the provided cert bundle.

### Whole Controller Logs

```shell
I don't have logs for the controller in this state as it cannot deploy.

Whole Runner Pod Logs
I don't have logs for any runners in this state as the controller cannot deploy.

Additional Context
This is really just a helm issue with how some of the values are handled. There are some sections where caBundle: {{ .Values.admissionWebHooks.caBundle }} is used and replacing with a {{ quote .Values.admissionWebHooks.caBundle }} fixes it. I also found the --log-format  arg that is provided to the controller manager command on the controller deployment is unrecognized after applying this fix. Dropping that from the chart fixes the deploy. After that it all seems to work fine. I have a fix for this that I have tested out locally and would have no problem putting up a PR if that makes this easier.

Thanks for filing this! Please feel free to submit a pull request 🙏

Closing this as resolved. Thanks a lot for your contribution @alexgQQ!


Add a Java based benchmark like Dicaobench or Java SciMark

http://www.dacapobench.org/

SciMark2 is now available in the dev branch. Closing this issue since it asked for DaCapoBench or Scimark - if there's interest in adding DaCapoBench separately, please file a new feature request for it.


[Bug] cloud meta service get_instance api returns success even when we pass invalid instance_id

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
master
What's Wrong?
cloud meta service get_instance api returns success even when we pass invalid instance_id
~/temp$ curl "<IP_ADDRESS>:5000/MetaService/http/get_instance?token=greedisgood9999&instance_id=cloud_instance_1";
{
"code": "OK",
"msg": "",
"result": {}
}
instance_id=cloud_instance_1 does not exist
What You Expected?
meta service get_instance api should return "failed to get instance" when invalid instance_id is passed
How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

already fixed


Copy tasks between some different file-systems (remote) hang with (os error 95)

What system are you running Yazi on?
Linux Wayland
What terminal are you running Yazi in?
kitty
yazi --debug output
Yazi
    Version: 0.3.3 (Nixpkgs 2024-09-04)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.3 (Nixpkgs 2024-09-04)

Emulator
    Emulator.via_env: ("xterm-kitty", "")
    Emulator.via_csi: Ok(Kitty)
    Emulator.detect : Kitty

Adapter
    Adapter.matches: Kitty

Desktop
    XDG_SESSION_TYPE           : Some("wayland")
    WAYLAND_DISPLAY            : Some("wayland-1")
    DISPLAY                    : Some(":0")
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: Some("0f594732b063a90d44df8c5d402d658f27471dfe_1728814821_51066977")
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/run/current-system/sw/bin/zsh")
    EDITOR             : Some("nvim")
    VISUAL             : None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })
    block  : Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : tmux 3.5a
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: 2.2.2
    magick           : 7.1.1-39
    fzf              : 0.55.0
    fd               : 10.2.0
    rg               : 14.1.1
    chafa            : 1.14.4
    zoxide           : 0.9.6
    7z               : 17.05
    7zz              : 24.08
    jq               : 1.7.1

Did you try the latest nightly build to see if the problem got fixed?
No, and I'll explain why below
Describe the bug
I'm copying files from a mounted ntfs3 volume (external USB HD) to a gvfs mounted samba share (i.e. accessed through /run/user/1000/gvfs/...).
I get many Failed to work on this task: Operation not supported (os error 95)
errors, and all tasks with the same source/destination hang. No further information is given.
It is not unusual to get some errors messages when copying between file-systems, these almost always refer to the inability to copy some kind of extended attribute, however, this type of error is/should be always treated non-fatally (more like a warning), this is the behaviour of all other known software (at least on linux).
Therefore, "not trying harder" to just copy the files and hanging instead should be considered a bug.
Expectation: issues regarding copying of extended attributes are reported as warnings, but the copying tasks are completed if no "real" errors (i.e. no write premission, disk full, ...) occur.
Minimal reproducer
Not sure, probably copying files with some kind of extended attributes to a gvfs mounted remote samba share?
Anything else?
No response

Seems a dup of https://github.com/sxyazi/yazi/issues/1703
Could you try this comment https://github.com/sxyazi/yazi/issues/1703#issuecomment-2381377074?

Seems a dup of #1703
Could you try this comment #1703 (comment)?

Thanks a lot for the quick reply.

It might seem similar, but it's definitely not "permission denied", with pretty much everything else I can copy without issue (now copying with rsync). Also The error is 95 and not 13, maybe that can tell us something more?
I'm currently not really able to spin up a rust file copy demonstrator to try bare rust functions like std::xxx... But maybe you know of a cli cp program that uses the same under the hood? Alternatively, can I get more verbose debugging in yazi, to a log file?

I'm currently not really able to spin up a rust file copy demonstrator to try bare rust functions like std::xxx... But maybe you know of a cli cp program that uses the same under the hood?

You can try Joshuto which it's also a file manager built with Rust

I've run into (what I think is) the same issue. Interestingly, running a shell command within yazi using the ":" key binding to create a file (e.g. touch test1.txt or echo "testing" > test2.txt) both succeed, as does using the 'a' key binding to create a file within yazi. It's only the yank-paste ("y" and "p" keybindings) workflow that seems to cause a hang.
It doesn't look like you have to be operating between different file systems either, as I was able to reproduce this yank-pasting a file from a samba share into the same directory. Also, it looks like the operation succeeds in creating the new file, but hangs at some point after that.
I've seen other discussions elsewhere with people having similar problems with the std::fs::copy function, and the hypothesis that "NTFS does not have chmod permissions, therefore attempting to set chmod permissions on a samba share will fail."
If I find the time, I'll try to play around with different versions of copy functions in Rust using my mounted file system, and see if I can isolate the issue and possibly suggest a fix.

Thanks @AidanJHMurphy, this info is really helpful!
It seems like Rust's std::fs::copy() does extra work related to file metadata (permissions) and raises a hard error for safety when it can't copy that metadata, even if the target filesystem doesn't support the operation at all.
I tried io::copy() and found it similar to the system call in fs::copy(), which means Yazi can still use copy_file_range to benefit from the Copy-on-write filesystem:
// fs::copy()

statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=13, ...}) = 0
openat(AT_FDCWD, "b", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0100644) = 4
statx(4, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
fchmod(4, 0100644)                      = 0
copy_file_range(3, NULL, 4, NULL,<PHONE_NUMBER>, 0) = 13
copy_file_range(3, NULL, 4, NULL,<PHONE_NUMBER>, 0) = 0
close(4)                                = 0
close(3)                                = 0

// io::copy()

statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=13, ...}) = 0
openat(AT_FDCWD, "b", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0100644) = 4
fchmod(4, 0100644)                      = 0
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=13, ...}) = 0
statx(4, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
copy_file_range(3, NULL, 4, NULL,<PHONE_NUMBER>, 0) = 13
copy_file_range(3, NULL, 4, NULL,<PHONE_NUMBER>, 0) = 0
close(4)                                = 0
close(3)                                = 0

But there are also some issues with this. It's currently unclear how macOS should implement it, since macOS's io::copy() just awkwardly copies byte by byte without using fclonefileat or fcopyfile.
That said, I'm not even sure if this problem exists on macOS, as no one has reported it yet.
Although Rust's fs::copy() implementation on macOS indeed treats failing to copy metadata as a hard error, it largely depends on whether the OS returns an error when these remote devices don't support metadata copying or fails silently.
Maybe we can try fixing it for Linux first. I'll create a PR for it later.

Please try https://github.com/sxyazi/yazi/pull/1805

Please try #1805

Thanks for looking into this so quickly!
It has become better in that it actually copies the files successfully, nice!
BUT: in the progressbar an error is still reported (red) and the task never finishes (even after the files have actually been copied). The errors are still reported (per file?), which is no problem by itself, but needs an error/warning distinction (see below).
So the error handling is not yet fixed.
Also, it would probably be helpful in general if in the detailed report of a selected task (i.e. w -> <select> -> [enter]) the object (file) name would be listed in the error line.
It is probably necessary to distinguish between "errors" and "warnings", so that we could arrive at a task state where a task could be "finished with errors" or "finished with warnings".
/reopen

Thanks for the test @ppenguin!

The errors are still reported

Can you elaborate a bit more? What error is it? Is it still the same os error 95, or has there been a change?
 Also a video demo of the operation would be helpful!

Thanks for the test @ppenguin!

The errors are still reported

Can you elaborate a bit more? What error is it? Is it still the same os error 95, or has there been a change?

Yes, it's the same list of same errors 95 (it seems there's one error report for every file if I select task details)

Are you using the latest commit df78827 (what does your yazi -V say) since I submitted a patch after that PR to fix a few edge cases. Also a video demo of the operation would be helpful!

> yazi -V
Yazi 0.3.3 (24a77d8 2024-10-19)

(last commit on master as of yesterday, two newer than the fix).
A side by side test "before/after" the fix:
Before:

(Note that the status remains at 0%, files are created but remain 0 B)

After

Now it gets interesting, with the same (limited) file set, everything is copied, even without errors, but some of the copied files are shown as empty, even if they're not (so a "refresh" would be necessary).
With another file set (nested dirs and more/larger files), I get this:

(note the red progress info, it gets stuck at 90%, even though everything was copied successfully => some files were non-zero length, but not fully copied!!!)

So in other words: the number of files for this case that is successfully copied went from "zero" to "more", but doesn't reliably work.

This is really strange, I've checked the code several times and can't find any errors, basically, Yazi is just using io::copy() on Linux instead of fs::copy():
https://github.com/sxyazi/yazi/blob/24a77d8a5f07f15d3b7d4651c9acf1e372ea5aef/yazi-shared/src/fs/fns.rs#L255-L276
My best guess is that std::io::copy() itself isn't working. If that's the case, there's really nothing more Yazi can do since this is the lowest-level API provided by Rust.
It could also be related to your environment. If possible, I suggest trying to call std::io::copy() directly in a Rust app to see if it works.
I'll mark this issue as "help wanted" and reopen it for a while to see if anyone can reproduce it on their system and debug it at the code level. Any help would be greatly appreciated! 🙏🏻

Just as some extra info:
if I just do cp -av between the same src/tgt I get errors like

cp: preserving permissions for ‘somefile.xxx’: Operation not supported for all files and
cp: failed to preserve ownership for 'somedir': Function not implemented for all dirs

But all files are copied completely.
This probably means that in the above code (I don't know any rust) the part where you are handling permissions in the target (unsafe { libc::fchmod(writer.as_raw_fd(), cha.perm) };) will probably also not be successful. This is probably the place where a "best effort" should be made to finish the operation and trhow a warning instead of an error.
To make sure that the contents (everything else than the metadata) has been indeed copied without difference, I'm not sure whether the part on L268~269 guarantees enough, or whether we'd need more checking?

Yes, the code above runs exactly as you described, with only the io::copy on line 268 being considered an error.
The subsequent libc::fchmod (for setting permissions) and set_times (for setting file access and modification times) attempt to execute as best as they can and fail silently. This means that even if they both fail, Yazi doesn’t see it as an error.
So, I really can’t imagine what could be causing the issue besides a problem with io::copy() itself. If it is indeed io::copy(), it likely means there’s no real "effective fix" for this issue since it’s the lowest-level API available to Yazi, and internally it’s just a wrapper around the copy_file_range system call.

So, I really can’t imagine what could be causing the issue besides a problem with io::copy() itself. If it is indeed io::copy(), it likely means there’s no real "effective fix" for this issue since it’s the lowest-level API available to Yazi, and in Rust internally, it’s just a wrapper around the copy_file_range [1], and sendfile [2] system call:

I just took a quick look for fun and education at the source of the "original" cp command (from coreutils) and surprise: it's thousands of loc long!
In other words, I'm not sure we should be looking for "the lowest level API" but for a higher level one, that is actually capable of handling all the complex ACL etc. stuff reliably. Hope this exists?
(I'd say this is pretty much mandatory, a copy program that can't handle the same as the cp baseline is ... well, not yet finished, I'm afraid  (Same with e.g. this one)

that is actually capable of handling all the complex ACL etc. stuff reliably. Hope this exists?

Yeah, I would love to switch to such an API if it exists and would accept a PR as long as it's reliable and implemented in Rust — I don't want to introduce a C library because that would complicate the build.
I noticed that another issue you raised with rcp describes the same problem as Yazi https://github.com/wykurz/rcp/issues/26, which likely means this issue affects all Rust programs using std::fs::copy() or std::io::copy() - I took a look at the source of rcp, and it calls tokio::fs::copy(), which is an async wrapper of std::fs::copy().
In this case, I'm going to close this issue since it's beyond what Yazi can handle and also not just specific to Yazi. I really suggest testing std::io::copy() on your system, it's pretty easy to do, if that fails as well, it's best to report it to Rust so all Rust programs can benefit, not just Yazi.

I noticed that another issue you raised with rcp describes the same problem as Yazi [wykurz/rcp#26]

I actually raised that to make the point that probably many/most rust based programs suffer from this

In this case, I'm going to close this issue since it's beyond what Yazi can handle and also not just specific to Yazi. I really

I understand, but this is a huge thing IMO, which would warrant a big red sticker on the product saying it's severly limited and only works on a limited set of file systems.

suggest testing std::io::copy() on your system, it's pretty easy to do, if that fails as well, it's best to report it to Rust so all

Basically I think we have already proven that both io::copy and fs::copy just can't handle this, so to test this again may be unnecessary. But I'll see what I can do when I happen to be bored :stuck_out_tongue_winking_eye:  (don't hold your breath though)

I just read the tokio source and noticed that its tokio::io::copy() isn't just a simple wrapper of std::io::copy(), but rather it implements its own userspace read-write loop.
I'm not sure if this is causing the issue, but I replaced it with std::io::copy() in https://github.com/sxyazi/yazi/pull/1817. Please give it a try; this is my last-ditch effort on this problem, hope it makes a difference 🤷🏻

Yes, I can confirm that #1817 works for the above test case!
This is a keeper :+1:


Red and Blue Nylium Blocks not spawning

Hi, so i downloaded and followed the instructions, starter island spawns but is missing th blue and red nylium blocks. Did i skip something by accident because i redownloaded and installed 2 more times after and still the same.

Nylium doesn't generate on the island anymore. You get it through nether portals.

Thank you, i thought i broke something, anyway awesome data pack man! Love it


Copy / Paste doesn't work

On Mac OS X  El Capitan & Chrome Version 50.0.2661.86 (64-bit)
Button copy / paste doesn't work

I use zeroclipboard, which use flash, perhaps it has something to to with it ?

are you able to use github "copy to clipboard" button ?

@gmarchand, any news on this ?


NEXT-36528 - Add intra community delivery label tax relevant documents

1. Why is this change necessary?
Tax consultants often require to have the information about intra-community label on all tax relevant documents (i.e. cancellation invoice).
2. What does this change do, exactly?
Adding a new option for intra-community delivery to the cancellation invoice and credit notes document settings page and adding a new method, like the one used in the invoice document file generator. This method checks, if the config is enabled and that all the necessary information is provided to show the label.
It adds a new is_eu field to the country entity to check if the customer is from the EU and a additional setting to adjust this in the countries settings page.
Removes the country selection list for the intra-community label option in the settings page of the documents.
3. Describe each step to reproduce the issue or behaviour.

Go to Settings -> Documents -> cancellation invoice
Activate the intra-community option.
Go to orders overview and create or select a order with a shipping address outside of the EU (e.g. United Kingdom).
Create a cancellation invoice under documents to this order.
An intra-community label should be displayed on the created document.

4. Please link to the relevant issues (if any).
https://issues.shopware.com/issues/NEXT-36528
5. Checklist

[x] I have rebased my changes to remove merge conflicts
[x] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@Bird87ZA Sure - Done!

Morning @magraina ,
We had some internal discussion yesterday and would like to understand the reasoning behind adding the EU states to the document config. We foresee a problem doing this where if the EU States change, the config will be outdated. And updating it, would affect all documents, even if they were from a valid EU state before the change. We realise that this functionality already exists in InvoiceRenderer so maybe it can be fixed in both places.
I would suggest adding a field to the document table that defaults to false. Then, when a document is created, a constant list of states is checked against the country and that field is then updated to true. In this instance, changing of EU States will be done in one place, and will only affect new documents that are created from that point on.
I'd like to hear if you have any other suggestion? Also, would you be willing to update this PR?

Hi @Bird87ZA,
I like that suggestion! Especially that this would not affect existing documents in case of a change.
I would suggest to add something like a is_eu field to the country table, which could then be checked for such functionalities. It could then also be changed independent from the software version when needed.
Sure, I'm willing to update this PR.

Good afternoon @magraina ,
During our internal review process, a question was raised about which documents should have this label. The consensus was that all tax-relevant documents (i.e. invoices, credit notes, cancellation invoices) and also quotation confirmations and delivery bills should have it.
Just thought I'd extend the opportunity to add this to you, as you've already started with this implementation. :)

Good afternoon @Bird87ZA,
I will keep that in mind for the implementation.
That might then be a small addition to get that for other documents as well.

Good afternoon @Bird87ZA,
I've updated the MR :)

@magraina apologies for only getting back to you now.
A few of the checks and linters are failing. Can you please have a look at it?
Other than that it looks good, and when these issues are fixed, we will merge it :)

@Bird87ZA sure!
I couldn't run them locally last week because my setup failed after merging the latest trunk.
So I was hoping for the CI

Good afternoon @Bird87ZA,
I've updated the MR :)
Can you run the CI again?

Your PR has been merged! Thanks for your contribution 💙

@Bird87ZA  Does this migration need a backport to Shopware 6.5? We upgraded some of our SW <IP_ADDRESS> environments to <IP_ADDRESS> and experienced the following error:

  // Warming up the cache for the acc environment with debug false

 In ExceptionConverter.php line 67:

   An exception occurred while executing a query: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'country.is_eu' in 'field list'

 In Exception.php line 28:

   SQLSTATE[42S22]: Column not found: 1054 Unknown column 'country.is_eu' in 'field list'

 In Statement.php line 130:

   SQLSTATE[42S22]: Column not found: 1054 Unknown column 'country.is_eu' in 'field list'

cache:warmup [--no-optional-warmers]

@sjerdo This looks to me like if you already have a certain change that requires the whole change from this PR.
The migration itself would solve the initial problem, but you will also need the other changes (e.g. on the UI) for this to work.


"Sorry, something went wrong" with Sign Up on DigitalOcean hosted docker droplet

The error seems to be happening in the compreface-ui when I attempt to Sign Up after running the installation process.
The first series of errors I think is occurring before I attempt to register. I have replaced my ip address below for privacy reasons.
Why is the code attempting to call the ip addresses <IP_ADDRESS> and <IP_ADDRESS>.  <IP_ADDRESS> is the IP address of the docker container for compreface-fe (compreface-ui). I can't figure out which contained the <IP_ADDRESS> IP address belongs to.
The error below appears several times "connect() failed (111: Connection refused) while connecting to upstream, client..."
 Create a new droplet on DigitalOcean with Docker 19.03.12 on Ubuntu 20.4 (there is a pre-existing install). This also installed Docker Compose by default.
2.) Download CompreFace_1.1.0.zip archive or run:
wget -q -O tmp.zip 'https://github.com/exadel-inc/CompreFace/releases/download/v1.1.0/CompreFace_1.1.0.zip' && unzip tmp.zip && rm tmp.zip
3.) To start CompreFace run:
docker-compose up -d
4.) Open in your browser: http://:8000/login
5.) Click on Create an account
6.) Enter your details and click Sign Up
Despite nothing being run on the droplet, without any calls to compreface the droplet still runs at CPU 100% every 5 minutes.

I don't think the problem is with compreface-ui, as you successfully opened this page.
I think the problem is with one of the other containers
Could you run:
docker ps
docker-compose logs
and share the responses?

IPv4 address for br-1407bfeb21c7: <IP_ADDRESS>
IPv4 address for docker0:         <IP_ADDRESS>
IPv4 address for eth0:            <IP_ADDRESS>
IPv4 address for eth0:            <IP_ADDRESS>
IPv4 address for eth1:            <IP_ADDRESS>
The REST call to admin/user/register in the browser to the api returns an error "Failed to load resource: the server responded with a status of 502 (Bad Gateway)"

Result from docker-compose logs from today:
compreface-api            | Listening for transport dt_socket at address: 5005
compreface-api            |
compreface-api            |   .   ____          _            __ _ _
compreface-api            |  /\ / ' __ _ () __  __ _ \ \ \
compreface-api            | ( ( )__ | '_ | '| | ' /  | \ \ \ \ compreface-api            |  \\/  ___)| |_)| | | | | || (_| |  ) ) ) ) compreface-api            |   '  |____| .__|_| |_|_| |_\__, | / / / / compreface-api            |  =========|_|==============|___/=/_/_/_/ compreface-api            |  :: Spring Boot ::               (v2.5.13) compreface-api            |  compreface-api            | 2022-10-22 07:40:40.110  INFO 6 --- [           main] com.exadel.frs.TrainServiceApplication   : Starting TrainServiceApplication v0.0.1-SNAPSHOT using Java 11.0.8 on 962a16485a81 with PID 6 (/home/app.jar started by root in /) compreface-api            | 2022-10-22 07:40:40.146  INFO 6 --- [           main] com.exadel.frs.TrainServiceApplication   : The following 1 profile is active: "dev" compreface-api            | 2022-10-22 07:40:40.691  WARN 6 --- [           main] o.s.b.c.config.ConfigDataEnvironment     : Property 'spring.profiles' imported from location 'class path resource [application.yml]' is invalid and should be replaced with 'spring.config.activate.on-profile' [origin: class path resource [application.yml] from app.jar - 94:13] compreface-api            | 2022-10-22 07:40:51.105  INFO 6 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode. compreface-api            | 2022-10-22 07:40:52.028  INFO 6 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 825 ms. Found 8 JPA repository interfaces. compreface-api            | 2022-10-22 07:40:57.799  INFO 6 --- [           main] o.s.cloud.context.scope.GenericScope     : BeanFactory id=9776d44d-52e1-38dc-b671-bd86977f22bf compreface-api            | 2022-10-22 07:41:01.543  INFO 6 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'cacheConfig' of type [com.exadel.frs.core.trainservice.config.CacheConfig$$EnhancerBySpringCGLIB$$8de28b80] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying) compreface-api            | 2022-10-22 07:41:05.271  INFO 6 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http) compreface-api            | 2022-10-22 07:41:05.376  INFO 6 --- [           main] o.a.coyote.http11.Http11NioProtocol      : Initializing ProtocolHandler ["http-nio-8080"] compreface-api            | 2022-10-22 07:41:05.378  INFO 6 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat] compreface-api            | 2022-10-22 07:41:05.379  INFO 6 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.62] compreface-api            | 2022-10-22 07:41:06.187  INFO 6 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext compreface-api            | 2022-10-22 07:41:06.188  INFO 6 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 25483 ms compreface-api            | 2022-10-22 07:41:10.416  INFO 6 --- [           main] o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [name: default] compreface-api            | 2022-10-22 07:41:11.266  INFO 6 --- [           main] org.hibernate.Version                    : HHH000412: Hibernate ORM core version 5.4.33 compreface-api            | 2022-10-22 07:41:11.281  INFO 6 --- [           main] org.hibernate.cfg.Environment            : HHH000205: Loaded properties from resource hibernate.properties: {hibernate.bytecode.use_reflection_optimizer=false, hibernate.types.print.banner=false} compreface-api            | 2022-10-22 07:41:13.269  INFO 6 --- [           main] o.hibernate.annotations.common.Version   : HCANN000001: Hibernate Commons Annotations {5.1.2.Final} compreface-api            | 2022-10-22 07:41:18.356  INFO 6 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting... compreface-api            | 2022-10-22 07:41:18.766  INFO 6 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed. compreface-api            | 2022-10-22 07:41:18.853  INFO 6 --- [           main] org.hibernate.dialect.Dialect            : HHH000400: Using dialect: org.hibernate.dialect.PostgreSQL10Dialect compreface-api            | 2022-10-22 07:41:21.080  INFO 6 --- [           main] o.h.validator.internal.util.Version      : HV000001: Hibernate Validator 6.2.3.Final compreface-api            | Killed compreface-api            | Listening for transport dt_socket at address: 5005 compreface-api            |  compreface-api            |   .   ____          _            __ _ _ compreface-api            |  /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \ compreface-api            | ( ( )\___ | '_ | '_| | '_ \/ _ | \ \ \
compreface-api            |  \/  )| |)| | | | | || (| |  ) ) ) )
compreface-api            |   '  || .__|| ||| |_, | / / / /
compreface-api            |  =========||==============|/=////
compreface-api            |  :: Spring Boot ::               (v2.5.13)
compreface-api            |
compreface-api            | 2022-10-22 07:42:00.873  INFO 6 --- [           main] com.exadel.frs.TrainServiceApplication   : Starting TrainServiceApplication v0.0.1-SNAPSHOT using Java 11.0.8 on 962a16485a81 with PID 6 (/home/app.jar started by root in /)
compreface-api            | 2022-10-22 07:42:00.906  INFO 6 --- [           main] com.exadel.frs.TrainServiceApplication   : The following 1 profile is active: "dev"
compreface-api            | 2022-10-22 07:42:01.347  WARN 6 --- [           main] o.s.b.c.config.ConfigDataEnvironment     : Property 'spring.profiles' imported from location 'class path resource [application.yml]' is invalid and should be replaced with 'spring.config.activate.on-profile' [origin: class path resource [application.yml] from app.jar - 94:13]
compreface-api            | 2022-10-22 07:42:08.910  INFO 6 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
compreface-api            | 2022-10-22 07:42:09.864  INFO 6 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 845 ms. Found 8 JPA repository interfaces.
compreface-api            | 2022-10-22 07:42:13.991  INFO 6 --- [           main] o.s.cloud.context.scope.GenericScope     : BeanFactory id=9776d44d-52e1-38dc-b671-bd86977f22bf
compreface-api            | 2022-10-22 07:42:17.111  INFO 6 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'cacheConfig' of type [com.exadel.frs.core.trainservice.config.CacheConfig$$EnhancerBySpringCGLIB$$55e6c6c] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
compreface-api            | 2022-10-22 07:42:19.812  INFO 6 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
compreface-api            | 2022-10-22 07:42:19.880  INFO 6 --- [           main] o.a.coyote.http11.Http11NioProtocol      : Initializing ProtocolHandler ["http-nio-8080"]
compreface-api            | 2022-10-22 07:42:19.881  INFO 6 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
compreface-api            | 2022-10-22 07:42:19.882  INFO 6 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.62]
compreface-api            | 2022-10-22 07:42:20.423  INFO 6 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
compreface-api            | 2022-10-22 07:42:20.424  INFO 6 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 19073 ms
compreface-api            | 2022-10-22 07:42:23.537  INFO 6 --- [           main] o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [name: default]
compreface-api            | 2022-10-22 07:42:24.554  INFO 6 --- [           main] org.hibernate.Version                    : HHH000412: Hibernate ORM core version 5.4.33
compreface-api            | 2022-10-22 07:42:24.575  INFO 6 --- [           main] org.hibernate.cfg.Environment            : HHH000205: Loaded properties from resource hibernate.properties: {hibernate.bytecode.use_reflection_optimizer=false, hibernate.types.print.banner=false}
compreface-api            | 2022-10-22 07:42:26.465  INFO 6 --- [           main] o.hibernate.annotations.common.Version   : HCANN000001: Hibernate Commons Annotations {5.1.2.Final}
compreface-api            |
compreface-api            |   .   ____          _            __ _ _
compreface-api            |  /\ / ' __ _ () __  __ _ \ \ \
compreface-api            | ( ( )__ | '_ | '| | ' / ` | \ \ \
compreface-api            |  \/  )| |)| | | | | || (| |  ) ) ) )
compreface-api            |   '  || .__|| ||| |_, | / / / /
compreface-api            |  =========||==============|/=////
compreface-api            |  :: Spring Boot ::               (v2.5.13)
compreface-api            |
compreface-api            | 2022-10-22 07:43:48.006  INFO 7 --- [           main] com.exadel.frs.TrainServiceApplication   : Starting TrainServiceApplication v0.0.1-SNAPSHOT using Java 11.0.8 on 962a16485a81 with PID 7 (/home/app.jar started by root in /)
compreface-api            | 2022-10-22 07:43:48.018  INFO 7 --- [           main] com.exadel.frs.TrainServiceApplication   : The following 1 profile is active: "dev"
compreface-api            | 2022-10-22 07:43:48.474  WARN 7 --- [           main] o.s.b.c.config.ConfigDataEnvironment     : Property 'spring.profiles' imported from location 'class path resource [application.yml]' is invalid and should be replaced with 'spring.config.activate.on-profile' [origin: class path resource [application.yml] from app.jar - 94:13]
compreface-api            | 2022-10-22 07:43:56.084  INFO 7 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
compreface-api            | 2022-10-22 07:43:57.061  INFO 7 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 875 ms. Found 8 JPA repository interfaces.
compreface-api            | 2022-10-22 07:44:01.438  INFO 7 --- [           main] o.s.cloud.context.scope.GenericScope     : BeanFactory id=9776d44d-52e1-38dc-b671-bd86977f22bf
compreface-api            | 2022-10-22 07:44:04.367  INFO 7 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'cacheConfig' of type [com.exadel.frs.core.trainservice.config.CacheConfig$$EnhancerBySpringCGLIB$$50285fb4] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
compreface-api            | 2022-10-22 07:44:07.673  INFO 7 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
compreface-api            | 2022-10-22 07:44:07.742  INFO 7 --- [           main] o.a.coyote.http11.Http11NioProtocol      : Initializing ProtocolHandler ["http-nio-8080"]
compreface-api            | 2022-10-22 07:44:07.744  INFO 7 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
compreface-api            | 2022-10-22 07:44:07.745  INFO 7 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.62]
compreface-api            | 2022-10-22 07:44:08.291  INFO 7 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
compreface-api            | 2022-10-22 07:44:08.295  INFO 7 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 19817 ms
compreface-api            | 2022-10-22 07:44:11.306  INFO 7 --- [           main] o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [name: default]
compreface-api            | 2022-10-22 07:44:12.447  INFO 7 --- [           main] org.hibernate.Version                    : HHH000412: Hibernate ORM core version 5.4.33
compreface-api            | 2022-10-22 07:44:12.469  INFO 7 --- [           main] org.hibernate.cfg.Environment            : HHH000205: Loaded properties from resource hibernate.properties: {hibernate.bytecode.use_reflection_optimizer=false, hibernate.types.print.banner=false}
compreface-api            | 2022-10-22 07:44:14.133  INFO 7 --- [           main] o.hibernate.annotations.common.Version   : HCANN000001: Hibernate Commons Annotations {5.1.2.Final}
compreface-api            | Killed
root@docker-CompreFace:~#

I've done a bit more testing and was able to install CompreFace on a Vultr docker instance without any difficulty. Had a couple of out of memory issues because I used a tiny configuration, but CompreFace ran perfectly. By default, Vultr doesn't create firewalls for everything.
I'm wondering if the default action of DigitalOcean blocking all ports could be the reason for the errors. I tried opening up ports 8080 and 8000 which are blocked by default but this didn't seem to make a difference.
Still getting Error 502, 'Bad Gateway', url: 'http://:8000/api/v1/consistence/status'

There is a chance DigitalOcean doesn't support the AVX technology required for CompreFace.
But from your screenshot and logs, I see that compreface-core service is running. And I don't see   compreface-core  logs.
I don't think that the problem is with the firewall.
By default, only one port is exposed, from what I see, you mapped it to 80 ports. CompreFace UI should send requests only to this port, so I think it should work as soon as you see UI.


Uncaught TypeError: Cannot read property 'split' of undefined

Hello, getting Uncaught TypeError: Cannot read property 'split' of undefined when select a day with monthly freq. in admin widget.
Uncaught TypeError: Cannot read property 'split' of undefined
    at recurrence.DateFormat.S (recurrence.js:451)
    at recurrence.DateFormat.<anonymous> (recurrence.js:303)
    at recurrence.js:906
    at Object.foreach (recurrence.js:877)
    at recurrence.DateFormat.format (recurrence.js:301)
    at Object.format (recurrence.js:837)
    at recurrence.js:158
    at Object.foreach (recurrence.js:877)
    at recurrence.Rule.get_display_text (recurrence.js:146)
    at recurrence.widget.RuleForm.get_display_text (recurrence-widget.js:983)

I was having the same issue. Looking at the recurrence.js file below, recurrence.langauage_code was always being set to undefined. Not sure why... but to solve, I changed line 448 to "var language_code = 'en-us'" and this solved the problem for me. This matched the language code that was in my Settings.py file.
You can quickly test this by setting recurrence.langauge_code to "en-us" in the inspect tool. and then seeing if the error is thrown.
This probably isn't the best solution but it worked for me and I didn't want to waste too much time on this issue.

Still have the same problem; here's a fix for anyone else:
<!-- The following script line is needed to shut up the MutationObserver for recurrence.js, and to show the recurrence field -->             <script>                 setTimeout(function(){                     (function(elements){                         if(elements.length > 0){ elements[0].id = "container" }                     })(document.getElementsByClassName('recurrence-widget'));                     // This line is needed to resolve this bug: https://github.com/django-recurrence/django-recurrence/issues/168                     recurrence.language_code = "en";                 }, 10);             </script>             <!-- media is loaded last -->

Aun tengo el mismo problema; aquí hay una solución para cualquier otra persona:
<!-- The following script is needed to shut up the MutationObserver for recurrence.js, and to show the recurrence field -->
<script>
    setTimeout(function(){
        (function(elements){
            if(elements.length > 0){ elements[0].id = "container" }
        })(document.getElementsByClassName('recurrence-widget'));
        // This line is needed to resolve this bug: https://github.com/django-recurrence/django-recurrence/issues/168
        recurrence.language_code = "en";
    }, 10);
</script>

    recurrence.language_code = "en";  fix this bug thanks @SteveHere

The bug is still not resolved. The developer shouldn't need to set language_code to en.


Dynamic Collapsible not working in React

I've tried to get a collapsible element working in React using .collapsible() in the following three ways
    componentDidMount() {
        this.collapsible.collapsible();
    }
    render() {
        ....
        return (
            <ul className="collapsible" data-collapsible="accordion" ref={input => this.collapsible = input }>
                { stuff }
            </ul>
        )
    }

which prints the error TypeError: this.collapsible.collapsible is not a function. (In 'this.collapsible.collapsible()', 'this.collapsible.collapsible' is undefined)
I've also tried explicitly using jQuery in componentDidMount both with and without React.findDOMNode to grab the element, also getting a complaint that collapsible does not exist. I am using version 0.98.0.

The issue I was having is that I was using the wrong version of jQuery :(


[FEATURE] Intel/Habana HPU Support

Integrate intel/Habana HPU kernel support for uint4 inference on Habana HPU. This was merged into AutoGPTQ https://github.com/AutoGPTQ/AutoGPTQ/pull/689/files but there are no ci tests and we have no access to habana hpu to even test this.
For this to work. We need:

Consistent access to habana HPU for ci testing/regression testing on all future releases. We will not merge any feature we cannot regression test against commits.
Create CI test to ensure the code works with valid PPL pre/post quantization on Habana HPU.

@HolyFalafel As the creator of the AutoGPTQ PR for habana HPU integration, do you know how or where to get developer access to Habana HPU for testing? Do you have contacts at Intel to allow us to get some credits for future regression testing. Without consistent access to Habana HPU, we will not even attempt to merge this feature since we will only merge that we can vouch and regression test for all future changes.  Thanks!

@Qubitium, I've forwarded it to relevant people in Habana.
They'll reply soon

@HolyFalafel I did not get any feedback on this from your contact. Can you tell me when or which email domain did they use? Thanks
My contact is<EMAIL_ADDRESS>and x handle @qubitium. We are willing spend to keep gptqmodel +  in sync habana support as long we can consistently run unit tests for tinyllama model that we like to use since llama structured model is dominant.

We are ramping for gptqmod 1.1 major release this weekend and want to slot in intel hpu support if possible. We can do the cherrypick from autogptq and merge and just need a small instance to run ci for aforementioned tinyllama 4bit inferenence


Simplify security config

Simplify security config,
we need JWT(idam) validation for UI faced endpoints and we do not need JWT for folder and segment endpoint which are only used by hrs-ingestor

https://tools.hmcts.net/jira/browse/EM-6031 is done instead of this PR.