remove the wrong annnotion

Purpose of the pull request
remove the wrong annotion

Codecov Report

Merging #5906 (4f2b9a6) into dev (8db1b04) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##                dev    #5906   +/-   ##
=========================================
  Coverage     46.74%   46.74%
  Complexity     3744     3744
=========================================
  Files           606      606
  Lines         24810    24810
  Branches       2828     2828
=========================================
  Hits          11597    11597
  Misses        12076    12076
  Partials       1137     1137

Impacted Files
Coverage Δ

...scheduler/service/queue/TaskPriorityQueueImpl.java
0.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 8db1b04...4f2b9a6. Read the comment docs.


setting default renderingBaseURL for production

Coverage remained the same at 97.51% when pulling 83c3a5cb1312efe889c92f7a925d51756e2a3855 on rendering-base-url into cae95ce409f8a7f2922f458e3d5d971d5cd2561d on major.


Update deviceinfo.d.ts

Description
Fixed issue #

Added yourNewMethodName() that allows ...
Compatibility

OS
Implemented

iOS
✅❌

Android
✅❌

Windows
✅❌

Checklist

[ ] I have tested this on a device/simulator for each compatible OS
[ ] I added the documentation in README.md.
[ ] I mentionned this change in CHANGELOG.md.

Can't a string be null in typescript ?

@machour not in strictNullChecks mode if I understand correctly. This means that TypeScript doesn't enforce a null check on a string, leading to potentially wrong code.


Removing enum to allow whatever warehouse id.

Hi, the warehouseid is a freely definable string in vtex, using an enum each person would have to include their own warehouses in the enum.

Hi @leandro-as is there any reason to close this PR without merging it ?

Working on this issue via #63 and #64


[HUDI-5317] Fix insert overwrite table for partitioned table

Change Logs
For sql like insert overwrite table $table select xxx, we expect to drop all data in the table first and then insert the selected data into it.  But we found that the 'insert overwrite table' semantic works only for non-partitioned table. For partitioned table, current implementation will drop only partitions involved in the select sub-query, other partitions won't be dropped( which should be dropped as expected).
This pr to solve the problem that  insert overwrite table can drop all partitions at first then insert new data.
Impact
Insert overwrite table will drop all partitions at first then insert new data.
Risk level (write none, low medium or high below)
None
Documentation Update
None
Contributor's checklist

[x] Read through contributor's guide
[x] Change Logs and Impact were stated clearly
[x] Adequate tests were added if applicable
[ ] CI passed

@leesf Could you please help to review this PR?

@stream2000 would you please check CI failure?

@hudi-bot run azure

@stream2000 would you please check CI failure?

Seems like some uts were failed. Will fix it

we have two operations relating to insert_overwrite. 1: insert_overwrite_table 2: insert_overwrite.
spark-ds writes supports both operations. insert_overwrite_table will override entire table. while insert_overwrite will overwrite only matching partitions.
guess in spark-sql, we supported only insert_overwrite. not sure if we can revert the behavior. May be we should consider adding a new write operation in spark-sql for this.

@nsivabalan hi, here are my two cents: insert overwrite xxx values(xx,xxx) has very clear semantics, it means overwrite the entire table, insert overwrite xx partition(xx) values(xx,xxx) means insert overwrite partitions, but hudi handles overwrite partitions for overwrite table, which is a definite bug and i do not think we need to introduce a new operation for it.

@hudi-bot run azure

@hudi-bot run azure

@hudi-bot run azure

@hudi-bot run azure

@hudi-bot run azure

@hudi-bot run azure


need to add .json to description of file names in synthetic

Hi.  line 31 has "List of file name (including extension) to retrieve and parse. Current implementation can parse .xml, .yml, .yaml, and .properties files"
should probably mention .json, as you now support it.
Thanks.

Thanks, will do!


[opentelemetry-operator] Add targets to update and check CRDs

Adds new make targets to update and check the operator CRDs.
Closes #298

Nice! Thanks @TylerHelmuth. Can you please all update this doc accordingly https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-operator/release/release-checklist.

Thanks for bringing this to my attention. I actually think I need to review the whole release folder, it looks like it also automatically updates the CRDs.

@Allex1 have you been using this release folder for the operator bumps?

@Allex1 have you been using this release folder for the operator bumps?

@TylerHelmuth  yes, I manually updated crds in ./charts/opentelemetry-operator/crds/ when bumping to 0.56.0 https://github.com/open-telemetry/opentelemetry-helm-charts/commit/628c218a46d619ba57fc86008ebd95fc02fe5074

@Allex1 take a look at https://github.com/open-telemetry/opentelemetry-helm-charts/pull/324 when you get a chance, I propose we remove the code in the release folder

@dmitryax @Allex1 how do you feel about a target like this:
.PHONY: update-crds-2
update-crds-2:
	APP_VERSION=$$(cat ./charts/opentelemetry-operator/Chart.yaml | sed -nr 's/appVersion: ([0-9]+\.[0-9]+\.[0-9]+)/\1/p') ; \
	git clone -b v$${APP_VERSION} --single-branch https://github.com/open-telemetry/opentelemetry-operator.git ./opentelemetry-operator
	cp -a ./opentelemetry-operator/config/crd/bases/. ./charts/opentelemetry-operator/crds
	rm -rf ./opentelemetry-operator

This option gets the entire CRD folder, so if a 3rd CRD is added we don't have to update our makefile.  It does require a rename of those files tho, bc currently our filenames don't match the operator repos

We might want to be aware of any new CDRs added to the operator. Not sure if we want to blindly fetch everything...

Not sure if we want to blindly fetch everything...

Ya thats how I felt too.  The old release code got the CRDs from the operator's manifest at https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml.  Or we could stick with this PR's current implementation.

We might want to be aware of any new CDRs added to the operator. Not sure if we want to blindly fetch everything...

I've mixed feelings as well: as I commented in https://github.com/open-telemetry/opentelemetry-helm-charts/issues/310 it's not like we make any use of the actual crds in this helm chart (other than deploying them in the cluster). So it might be useful for some users to get any new crds as soon as they become available in order to start using them. On the other hand it seems like a trivial change to add any eventual extra crds ... so I'm fine either way.


Add --force-local flag to lxc and document others + fix and tweak travis a bit

Signed-off-by: Stéphane Graber<EMAIL_ADDRESS>

I was going to wait a while and see how reliable osx is on travis, but we can do it the other way around too, pushed a commit to change to not allowing failures.


LIVE-1748 Prevent crash when using proxy device

Type
Bugfix
Context
https://ledgerhq.atlassian.net/browse/LIVE-1748
Parts of the app affected / Test plan

Start the app using a proxy device
Try accessing the manager with that device
See if it crashes or not, it shouldn't!

Nobody seems to be able to test this since we can't get the proxy to work at all on LLM.
Since this is essentially used for dev and @gre is off now, we can wait until he's back. I believe the fix is clear and should work so it should be harmless to merge.


fix for collapsed forwarding ink_abort for CacheHitFresh fail

This fixes an abort when
CONFIG proxy.config.http.cache.open_write_fail_action INT 5
is set which rewinds the state machine to before cache read/write.
This was tested by simulating a manifest that updates every 10s with max-age=1 cache control, hitting that asset with a thundering herd.
The failure was happening with a cache hit on a stale manifest.
While this "fix" allows ATS to to run without aborting, under testing 1 or more transactions end up with a client timeout with no bytes transferred.

[approve ci debian]

Cherry-picked to v9.2.x


Bad dex magic dex

Hi,
I'm getting the following issue when running with APK's
INFO Initializing Redex...
error: /tmp/mt-static-cnhs17k0/build/redex-master/libredex/DexLoader.cpp:49: void validate_dex_header(const dex_header*, size_t, int): assertion `supported' failed.
Bad dex magic dex
039 for support_dex_version 37

Any help here would be great.
Thanks

I resolved this issued by:
1、set up the development environment
2、before re-compiled the redex, add dex version 39 support in the redex\libredex\DexLoader.cpp
static void validate_dex_header(const dex_header* dh,
size_t dexsize,
int support_dex_version) {
bool supported = false;
switch (support_dex_version) {
case 39:
supported = supported ||
!memcmp(dh->magic, DEX_HEADER_DEXMAGIC_V39, sizeof(dh->magic));
case 38:
supported = supported ||
!memcmp(dh->magic, DEX_HEADER_DEXMAGIC_V38, sizeof(dh->magic));
3、modify the default support dex version to 39 in the source/MarianaTrench.cpp
void MarianaTrench::run(const program_options::variables_map& variables) {
...
context.stores = init(
boost::join(system_jar_paths, ","),
options.apk_directory(),
options.dex_directory(),
/* balloon / true,
/ support_dex_version */ 39);
4、build the mariana-trench

Redex might not support version 39. Please open an issue at https://github.com/facebook/redex

We were able to get that working, Thank you.

I have the same problem, is there an update?


error messaging Exchange contract

After installing exchange (and currency) contracts and pushing a message I get a conversion error:
./eosc push message currency transfer '{"from":"user1","to":"exchange","quantity":1000}' --scope exchange,user1 -p user1@active
./eosc push message exchange bid '{"buyer":{"name":"user1","number":123},"at_price":100,"quantity":10,"expiration":"2017-12-12","fill_or_kill" : 0}' --scope exchange,user1 -p user1@active
Error message from eosc
383246ms            main.cpp:1099                 operator()           ] Converting argument to binary... 383270ms            main.cpp:1166                 main                 ] Failed with error: Assert Exception (10) status_code == 200: Error code 500 : {"code":500,"message":"Internal Service Error","details":"7 bad_cast_exception: Bad Cast\nInvalid cast from object_type to string\n    {\"type\":\"object_type\"}\n      variant.cpp:476 as_string\n\n    {\"code\":\"exchange\",\"type\":\"bid\",\"obj\":{\"buyer\":{\"name\":\"user1\",\"number\":123},\"at_price\":100,\"quantity\":10,\"expiration\":\"19-12-2017\",\"fill_or_kill\":0}}\n      chain_controller.cpp:1555 message_to_binary"}
Error message rom eosd
383249ms            chain_api_plugin.cpp:71       operator()           ] Exception encountered while processing chain.abi_json_to_bin: {"code":7,"name":"bad_cast_exception","message":"Bad Cast","stack":[{"context":{"level":"error","file":"variant.cpp","line":476,"method":"as_string","hostname":"","thread_name":"","timestamp":"2017-12-13T04:06:23"},"format":"Invalid cast from ${type} to string","data":{"type":"object_type"}},{"context":{"level":"warn","file":"chain_controller.cpp","line":1555,"method":"message_to_binary","hostname":"","thread_name":"","timestamp":"2017-12-13T04:06:23"},"format":"","data":{"code":"exchange","type":"bid","obj":{"buyer":{"name":"user1","number":123},"at_price":100,"quantity":10,"expiration":"19-12-2017","fill_or_kill":0}}}]}
At first, I thought is the time(expiration) field format, so I tried 2018-01-01, 2018/01/01, 01/01/2018, 01-01-2018,<PHONE_NUMBER> (epoch) - with no luck.
Now I believe its the nested json object buyer of typeorder_id

bid is not an action https://github.com/EOSIO/eos/blob/master/contracts/exchange/exchange.abi#L51

Please use telegram EOS Developers for support.


Binary streaming of headers

Closes #1330.

ImmutableDB: add a header envelope

ChainDB.ImmDB: allow reading just the header

ChainDB.Reader: split readers into block and header readers

Add codecChainSyncSerialised

ChainDB: let Readers return Deserialisable headers/blocks

ChainSyncServer: stream binary headers/blocks

ChainDB.Reader: add ReaderInit state as an optimisation

TODO: includes #1323 until that gets merged.
TODO: depends on #1309, which is not yet done. The tests currently fail with an error because of this.

@kderme: just a heads-up: https://github.com/input-output-hk/ouroboros-network/pull/1331/commits/0162c894f31fae558324c0e73085c1818033773b

bors r+


No profile_image_url in includes.users - twitter-api-v2

 const tweetOfId20 = await roClient.v2.singleTweet(TweetId, {               expansions: [                 'author_id',                                 'entities.mentions.username',                 'in_reply_to_user_id',                 'referenced_tweets.id',                 'referenced_tweets.id.author_id'               ],             });
The response includes Id, Name and Username but no profile_image_url

Please how the expansions for this endpoint works.
You need to add 'user.fields': ['profile_image_url'] to get this property.


Upd: add character to gsmvalidator

Thanks for the pull request, but I do not believe that the grave accent (or "backtick" `) character has any place in the currently supported GSM Basic Character Set.
If you are having issues with this package and its support for a particular character set (for example, Portuguese language (Latin script) which includes the backtick at 0x7D) then you should open a pull request with full support for that character set.
I release that there has not been a clear path set out for support of such a character set, so it does need some thought.
If you wish to do this, please also ensure you include a full test suite for the character set in its entirety to ensure that regressions cannot be made.


Clarification on FIDO2 support status

The page at https://learn.microsoft.com/en-us/entra/identity/authentication/fido2-compatibility details FIDO2 combability with iOS and Android, however this page seems to have an outdated statement:
As of February 2021, FIDO2 is not currently supported for native iOS or Android apps, but it is in development.
Is there any newer guidance?

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 6f22cc9c-eabe-842d-1606-9725ddd69d73
Version Independent ID: b0bcebe2-07f0-2bd9-3e26-eb5553d9838a
Content: Support passwordless authentication with FIDO2 keys in apps you develop - Microsoft identity platform
Content Source: docs/identity-platform/support-fido2-authentication.md
Service: active-directory
Sub-service: develop
GitHub Login: @henrymbuguakiarie
Microsoft Alias: henrymbugua

@bubbletroubles
Thanks for your feedback! We will investigate and update as appropriate.

@bubbletroubles
I apologize for the confusion. The statement on the page you mentioned is outdated and no longer accurate.
As of September 2021, FIDO2 is supported on native iOS and Android apps. Microsoft has released the Microsoft Authenticator app for iOS and Android, which supports FIDO2 authentication.
You can find more information about FIDO2 compatibility with Microsoft products on the following page: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys
I apologize for any confusion caused by the outdated information on the page you mentioned. We will work to update the page with the latest information.

@henrymbuguakiarie
Could you Please review this and update as appropriate.

@bubbletroubles
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation


Metric contexts: figure out how to best wrap/extend the MLFlow client API

#209 and #363 will require us to wrap/extend the MLFlow client API in our Python package. This issue is about figuring out the best approach for shipping that in our Python package.

I've created a package called fasttrackml.
This package allows users to access all the functionalities of MLFlow while introducing an additional function, log_metric_with_context.
This function retains the same parameters as log_metric but also accepts a dict representing the context.
In implementing this, I followed the existing structure of MLFlow for managing metric log, creating subclasses of the existing ones. I've created a new entity called Metric_with_context which is basically equal to a normal Metric but has a new context field.

fluent_context_support.log_metric_with_context --> Log a metric with context under the current run. If no run is active, this method will create a new active run
MlflowClientExtend --> is a sub-class of MlflowClient which provides log_metric_with_context method
ContextsupportStore --> is a sub-class of RestStore allow us to create a json for the log metric with context request. In order to enable the new metric to be serialized in JSON format, I have also written a proto file for the metric_with_context .

all the changes can be found here: https://github.com/fabiovincenzi/fasttrack/tree/python-mlflow-wrapper

Very interesting @fabiovincenzi!
Here are a few questions:

could you try this with renaming log_metric_with_context to log_metric but with the additional optional named parameter context?
is there any way to serialize to JSON without having to copy over the protos? we don't have to support databricks implementation, so we may as well veer away from this hard-to-maintain mess
could you please give an example of what the UX looks like with an example script that logs metrics with contexts?

Okay @jgiannuzzi, now the MLFlow log_metric has been overridden with our new implementation including an optional context parameter.
I removed scalapb and databricks protos by importing them directly from mlflow.
Here is an example of the UX:
from random import randint, random

import fasttrackml
from fasttrackml import log_metric, log_param

fasttrackml.set_tracking_uri("http://localhost:5000")
fasttrackml.set_experiment("my-experiment")

if __name__ == "__main__":
    # Log a parameter (key-value pair)
    log_param("param1", randint(0, 100))

    # Log a metric without context
    log_metric("foo", random())
    # Log a metric with context
    log_metric("foo", random() + 1, context={'subset': 'train'})

New changes made for:

serializing the new metrics with context without using photos
importing all of the mlflow methods and overriding them with custom log_metric

https://github.com/fabiovincenzi/fasttrack/tree/python-mlflow-wrapper


Rename members to collaborators

I might be able to help with this if I knew exactly what the task was.

The idea was to harmonize our nomenclature between front-end and backend. However, I'm not sure this is a priority since this only applies to projects with distributing, and Gratipay is the only one of those we have right now. I think we should close this and revisit the matter when we get to https://github.com/gratipay/gratipay.com/issues/3433.

#4156 is actually more important—and more difficult.


rbd: the length of args on create_v3 should be 3 instead of 2

the length of args on create_v3 should be 3 instead of 2

@noahdesu any reason this should not be merged?

@noahdesu thanks for merge helping 👍


Can't enable static, ip address Ip[5.xxx.xxx.xx-1] is a sourceNat ip address

If I add the bellow option to the terraform, I get this error in the first deploy:
cloudstack_network.terra-net: Creating...
cloudstack_network.terra-net: Creation complete after 1s [id=f0b8709c-6013-4d80-9075-cc26b826f5a6]
cloudstack_ipaddress.default: Creating...
cloudstack_instance.web: Creating...
cloudstack_ipaddress.default: Creation complete after 0s [id=907d5b89-cf2f-4109-ba83-78e620a5b431]
cloudstack_firewall.default: Creating...
cloudstack_instance.web: Still creating... [10s elapsed]
cloudstack_instance.web: Still creating... [20s elapsed]
cloudstack_instance.web: Still creating... [30s elapsed]
cloudstack_instance.web: Still creating... [40s elapsed]
cloudstack_instance.web: Still creating... [50s elapsed]
cloudstack_instance.web: Still creating... [1m0s elapsed]
cloudstack_instance.web: Still creating... [1m10s elapsed]
cloudstack_instance.web: Creation complete after 1m19s [id=00fa3d62-0d22-470d-81fc-477bbc5d3bea]
cloudstack_static_nat.default: Creating...
╷
│ Error: Error enabling static NAT: CloudStack API error 431 (CSExceptionErrorCode: 4350): Can't enable static, ip address Ip[5.xxx.xx.xx-1] is a sourceNat ip address
│
│   with cloudstack_static_nat.default,
│   on acs.tf line 49, in resource "cloudstack_static_nat" "default":
│   49: resource "cloudstack_static_nat" "default" {
│
╵
╷
│ Error: 1 error occurred:
│       * Undefined error: {"errorcode":530,"errortext":"Failed to create firewall rule"}
│
│
│
│   with cloudstack_firewall.default,
│   on acs.tf line 60, in resource "cloudstack_firewall" "default":
│   60: resource "cloudstack_firewall" "default" {
│
`╵`

If I do another run after this, it will work, the problem is that only 1 public IP is allocated by default and the default one is with source NAT which can not be changed to static NAT.
Is there a way to specify the public IP quantity? ( like it is possible via API ) or how can be this done only with 1 run?
This is how the deploy code looks.
resource "cloudstack_network" "terra-net" {
  name             = "terra-net"
  cidr             = "<IP_ADDRESS>/24"
  network_offering = "eb986523-8375-4824-8091-126a61e6ef05"
  zone             = "DE-001"
}
resource "cloudstack_instance" "web" {
  name             = "terratestacs"
  service_offering = "Micro"
  network_id       = cloudstack_network.terra-net.id
  template         = "7c01984d-f5ab-4638-b7a0-cb427f49523d"
  zone             = "DE-001"
  keypair          = "terrakey"

  user_data = <<-EOF
                #!/bin/bash
                sudo apt update -y
                sudo apt install apache2 -y
                sudo systemctl start apache2
                sudo bash -c 'It is up > /var/www/html/index.html'
                systemctl enable apache2.service
                EOF
  #expunge = true
  root_disk_size   = "10"
}

resource "cloudstack_ipaddress" "default" {
  network_id = cloudstack_network.terra-net.id
}

resource "cloudstack_static_nat" "default" {
  ip_address_id      = cloudstack_ipaddress.default.id
  virtual_machine_id = cloudstack_instance.web.id
}

output "acs_ip_address" {
  value = cloudstack_instance.web.ip_address

}

resource "cloudstack_firewall" "default" {
  ip_address_id = cloudstack_ipaddress.default.id

  rule {
    cidr_list = ["<IP_ADDRESS>/0"]
    protocol  = "tcp"
    ports     = ["80", "443", "22"]
  }
}

Hi @ccycv did it used to work with an older version of the TF provider?

Hi @ccycv, I'm closing the ticket as the error seems valid. Please reopen in case if anything to add.


autoruns: Add version 14.09

Added a manifest for an utility from windows: "This utility, which has the most comprehensive knowledge of auto-starting locations of any startup monitor, shows you what programs are configured to run during system bootup or login, and when you start various built-in Windows applications like Internet Explorer, Explorer and media players. These programs and drivers include ones in your startup folder, Run, RunOnce, and other Registry keys. Autoruns reports Explorer shell extensions, toolbars, browser helper objects, Winlogon notifications, auto-start services, and much more. Autoruns goes way beyond other autostart utilities."
https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns

[X] I have read the Contributing Guide.

Oh, i forgot to implement "checkver". I should amend that.

/verify Checkver Syntax added

Hmm, okay. Didn't see that. scoop search autoruns delivered me no output. Sad that it's not searching in the shortcut descriptions for it, so this wouldn't so confusing and misleading. 🙂

That's an excellent point. scoop could search in the manifest's bin and shortcuts sections. In fact, I thought it did.


cert-manager-cainjector not work

Environment details::

Kubernetes version: 1.17.x
Cloud-provider/provisioner: provisioner
cert-manager version:  1.6.3
Install method: e.g. helm/static manifests:   manifests

/kind bug
I0524 02:38:37.859278       1 controller.go:240] cert-manager/certificate/customresourcedefinition/controller/controller-for-certificate-customresourcedefinition "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859279       1 reflector.go:225] Stopping reflector *v1.CustomResourceDefinition (10h49m58.764554377s) from external/io_k8s_client_go/tools/cache/reflector.go:167
E0524 02:38:37.859386       1 start.go:139] cert-manager/ca-injector "msg"="manager goroutine exited" "error"=null
I0524 02:38:37.859391       1 controller.go:240] cert-manager/certificate/apiservice/controller/controller-for-certificate-apiservice "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859433       1 controller.go:242] cert-manager/certificate/apiservice/controller/controller-for-certificate-apiservice "msg"="All workers finished"
I0524 02:38:37.859460       1 controller.go:240] cert-manager/certificate/mutatingwebhookconfiguration/controller/controller-for-certificate-mutatingwebhookconfiguration "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859452       1 reflector.go:225] Stopping reflector *v1.CustomResourceDefinition (9h14m26.595457864s) from external/io_k8s_client_go/tools/cache/reflector.go:167
I0524 02:38:37.859484       1 controller.go:240] cert-manager/certificate/validatingwebhookconfiguration/controller/controller-for-certificate-validatingwebhookconfiguration "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859484       1 controller.go:240] cert-manager/secret/apiservice/controller/controller-for-secret-apiservice "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859486       1 reflector.go:225] Stopping reflector *v1.ValidatingWebhookConfiguration (10h4m34.684255596s) from external/io_k8s_client_go/tools/cache/reflector.go:167
I0524 02:38:37.859539       1 controller.go:240] cert-manager/secret/customresourcedefinition/controller/controller-for-secret-customresourcedefinition "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859553       1 controller.go:240] cert-manager/secret/validatingwebhookconfiguration/controller/controller-for-secret-validatingwebhookconfiguration "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859565       1 controller.go:240] cert-manager/secret/mutatingwebhookconfiguration/controller/controller-for-secret-mutatingwebhookconfiguration "msg"="Shutdown signal received, waiting for all workers to finish"
I0524 02:38:37.859564       1 controller.go:242] cert-manager/certificate/customresourcedefinition/controller/controller-for-certificate-customresourcedefinition "msg"="All workers finished"
I0524 02:38:37.859590       1 controller.go:242] cert-manager/certificate/validatingwebhookconfiguration/controller/controller-for-certificate-validatingwebhookconfiguration "msg"="All workers finished"
I0524 02:38:37.859590       1 reflector.go:225] Stopping reflector *v1.APIService (9h13m58.50001062s) from external/io_k8s_client_go/tools/cache/reflector.go:167
I0524 02:38:37.859680       1 reflector.go:225] Stopping reflector *v1.Secret (9h57m39.083932972s) from external/io_k8s_client_go/tools/cache/reflector.go:167
I0524 02:38:37.859696       1 controller.go:242] cert-manager/secret/customresourcedefinition/controller/controller-for-secret-customresourcedefinition "msg"="All workers finished"
I0524 02:38:37.859716       1 controller.go:242] cert-manager/secret/mutatingwebhookconfiguration/controller/controller-for-secret-mutatingwebhookconfiguration "msg"="All workers finished"
I0524 02:38:37.859686       1 controller.go:242] cert-manager/certificate/mutatingwebhookconfiguration/controller/controller-for-certificate-mutatingwebhookconfiguration "msg"="All workers finished"
I0524 02:38:37.859743       1 controller.go:242] cert-manager/secret/apiservice/controller/controller-for-secret-apiservice "msg"="All workers finished"
I0524 02:38:37.859739       1 controller.go:242] cert-manager/secret/validatingwebhookconfiguration/controller/controller-for-secret-validatingwebhookconfiguration "msg"="All workers finished"
I0524 02:38:37.859783       1 reflector.go:225] Stopping reflector *v1.MutatingWebhookConfiguration (10h15m19.057026228s) from external/io_k8s_client_go/tools/cache/reflector.go:167

Hi, can you please upgrade to a newer version and see if that solves the problem? 1.6 is no longer supported https://cert-manager.io/docs/installation/supported-releases/


[BUG] new wallet fails on depositing

need to generate public key for fresh wallet

https://github.com/xchainjs/xchainpy-lib/commit/fe4f2a6ebb408c119c4571636f1d8f23d0aa69c6


Convert ingest processor supports ip type

Description
In release 2.14.0, the convert ingest processor will support ip type, we need to document that.
Issues Resolved
https://github.com/opensearch-project/documentation-website/issues/6784
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@hdhalter please help to review this PR, thank you!


JSON Locked issue still happening with 1.3.1

Using go2rtc 1.3.1 with Frigate 12rc2, I still lose connection to some of my cams, and they do not reconnect, I assume because of the json locked.
2023-04-03 12:51:49.078610275  [INFO] Preparing go2rtc config...
2023-04-03 12:51:49.120227209  [INFO] Got IP address from supervisor: <IP_ADDRESS>
2023-04-03 12:51:49.164097367  [INFO] Got WebRTC port from supervisor: 8555
2023-04-03 12:51:49.392745529  [WARN] Using go2rtc binary from '/config/go2rtc' instead of the embedded one
2023-04-03 12:51:49.392750086  [INFO] Starting go2rtc...
2023-04-03 12:51:49.490440378  14:51:49.490 INF go2rtc version 1.3.1 linux/amd64
2023-04-03 12:51:49.490662830  14:51:49.490 INF [api] listen addr=:1984
2023-04-03 12:51:49.490889496  14:51:49.490 INF [rtsp] listen addr=:8554
2023-04-03 12:51:49.491067962  14:51:49.491 INF [srtp] listen addr=:8443
2023-04-03 12:51:49.491184317  14:51:49.491 INF [webrtc] listen addr=:8555/tcp
2023-04-03 12:51:50.443922298  14:51:50.443 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 12:51:50.481478208  14:51:50.481 DBG [rtsp] new consumer stream=Kitten_cam
2023-04-03 12:51:50.484877985  14:51:50.484 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 12:51:50.495647591  14:51:50.495 DBG [rtsp] new consumer stream=Parking_cam
2023-04-03 12:51:50.580767114  14:51:50.580 DBG [streams] start producer url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 12:51:50.595977633  14:51:50.595 DBG [streams] start producer url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 12:51:50.736987736  14:51:50.736 DBG [streams] start producer url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 12:51:50.800421587  14:51:50.800 DBG [streams] start producer url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 12:51:59.083364737  [INFO] Starting go2rtc healthcheck service...
2023-04-03 14:26:23.218136944  16:26:23.217 WRN github.com/AlexxIT/go2rtc/cmd/streams/producer.go:157 > error="read tcp <IP_ADDRESS>:34360-><IP_ADDRESS>:554: i/o timeout" url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 14:26:23.218202252  16:26:23.218 DBG [streams] retry=0 to url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 14:26:23.275297935  16:26:23.275 WRN github.com/AlexxIT/go2rtc/cmd/streams/producer.go:157 > error="read tcp <IP_ADDRESS>:34072-><IP_ADDRESS>:554: i/o timeout" url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 14:26:23.275360023  16:26:23.275 DBG [streams] retry=0 to url=rtsp://<IP_ADDRESS>:554/onvif1
2023-04-03 14:26:48.943975563  16:26:48.943 DBG [rtsp] handle=EOF
2023-04-03 14:26:49.027528208  16:26:49.027 DBG [rtsp] handle=EOF
2023-04-03 14:26:50.734895198  16:26:50.734 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:26:50.745672772  16:26:50.745 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:27:00.770336169  16:27:00.770 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:27:00.773562070  16:27:00.773 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:27:04.048719783  16:27:04.048 WRN [streams] json locked
2023-04-03 14:27:04.049063227  16:27:04.048 WRN [streams] json locked
2023-04-03 14:27:10.781465236  16:27:10.781 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:27:10.782343046  16:27:10.782 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:27:20.790554227  16:27:20.790 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:27:20.796829776  16:27:20.796 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:27:30.821114853  16:27:30.821 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:27:30.827880803  16:27:30.827 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:27:34.077220650  16:27:34.077 WRN [streams] json locked
2023-04-03 14:27:34.077616409  16:27:34.077 WRN [streams] json locked
2023-04-03 14:27:40.847559616  16:27:40.847 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:27:40.855200537  16:27:40.855 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:27:50.885540528  16:27:50.885 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:27:50.890139199  16:27:50.890 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:28:00.925395060  16:28:00.925 DBG [rtsp] new consumer stream=Garden_cam
2023-04-03 14:28:00.927205567  16:28:00.927 DBG [rtsp] new consumer stream=Shed_cam
2023-04-03 14:28:04.106011942  16:28:04.105 WRN [streams] json locked
2023-04-03 14:28:04.106645818  16:28:04.106 WRN [streams] json locked

Are you sure that the configuration file is not at the readonly mount point and that's contents meet your expectations?

Yes. The 2 other cameras I have work properly, and all reconnect if I restart the frigate add-on (and therefore the go2rtc)

Same issue here, go2rtc 1.3.1 and I have 1 camera that will sometimes go down and go2rtc never reconnects to it and I get the json locked error repeated.

@AlexxIT Please tell me if I need to get you more verbose logging to troubleshoot the issue. The problem occurs several time a day, so it is not a problem to find additional information if needed.

Looks like 1.3.2 improved the (re)connections. Haven't seen the json lock issue since yesterday. Will keep issue open a couple of days to confirm. Thanks !

Yes. RTSP has been reworked. You can reopen issue if you get problem again.


Added auto doc generation

added sphinx configuration to create documentation from docstrings
fixed some sphinx warnings in docstrings
added script that recreates documentation after each commit and commit
it to gh-pages

@jmcgeheeiv - I have played around with sphinx and autodoc and came up with this. Please check if this makes sense at all.
There is least one problem with this approach: always the latest version of the documentation is shown on GitHub pages, even if it is not released. One way to handle this could be to mention new functionality in the docstrings (e.g. "new  in pyfakefs 2.9"). What do you think?
And, somewhat related (in case I will adapt the docstrings) - what will be the next version? 2.10 or 3.0?
Ah, and I promise to leave this alone for a while when done with the documentation stuff (at least if no bugs come in) :P

@mrbean-bremen you needn't promise to do nothing to move pyfakefs forward.
While version 2.10 is correct per semantic versioning, I think we are ready to step up to 3.0: the @mrbean-bremen version with solid Windows support.
So let's follow the standard Python documentation convention of saying, "New in version 3.0."
Where is this documentation rendered?  You might mention the location in README.md.

Well, I didn't want to bother you too much - you may have more important things to do (and maybe recover from 11/8) ;)
Ok - thanks, I will add the version information in the docstrings where needed. I already added a mention in README.md in the PR - you may have overlooked that one (the URL is http://jmcgeheeiv.github.io/pyfakefs). Note that the documentation is just auto-generated and certainly needs some work, but it may suffice for now.

I feel bad for leaving you to your own devices with Sphinx.  I actually use it quite a bit at work.
I think that the Sphnix documentation is more than adequate for now.  Nice job.

That's completely ok for me - I learned something new (I only used doxygen for documentation generation until now, had no need for Python documentation yet). So I will adapt the docstrings somewhere in the next days and push the PR, if you have no objections.

I added "New in pyfakefs 3.0" instead of "New in version 3.0" to avoid to confuse it with the python version, so now it may read "New in python 3.3. New in pyfakefs 3.0" or similar. I will merge the PR later, in case you have no further remarks.

New, new, new!  I love that word!

:) If you don't have any further plans for this version, we could indeed go ahead with the 3.0 version.

@jmcgeheeiv - I'm mostly done with the autodoc stuff, but it doesn't work in the master branch due to my access token not working from your repository (at least this is what I guess, as it works from my branch) - I need this to push the documentation into the gh-pages branch. While this is not a big deal (could always manually commit changes), I would just like t to work... So if you get some time, you could replace the token with one of yours. How to do this:

remove the current token from .travis.yml (e.g. the env stuff)
install the ruby gem travis (gem install travis) (there is an alternative using node.js and Python which I haven't tried)
under your GitHub settings, go to Personal Access Tokens, create a new token that has (only) "public_repo" right set and copy it somewhere
in the repo root of pyfakfs, execute:
travis encrypt GH_TOKEN= --add env.global
edit the diff of .travis.yml (the script deletes comments) and commit it

Thanks in advance!

@jmcgeheeiv - ok, forget my last comment, it may not be worth the trouble. I will just manually update the docs before a release. Speaking of releases - I think it may be time for one more - there have been some features added since 2.9, and at least I am not planning any more changes at the moment.. What do you think?


vite plugin does not support HMR

Describe the bug
I've created a fresh vite project via yarn create vite vite-vanilla-extract-test --template react- ts and set up vanilla extract. Here's the vite.config.ts:
import {defineConfig} from "vite";
import reactRefresh from "@vitejs/plugin-react-refresh";
import {vanillaExtractPlugin} from "@vanilla-extract/vite-plugin";

export default defineConfig({
  plugins: [reactRefresh(), vanillaExtractPlugin()],
})

Changing any file css.tsx leads to a full refresh of the page which makes iterating on styles rather cumbersome.
For experimentation, I've created a *.module.css file. And here it does work as expected and you'll find this line in the logs:

Not sure whether it's a known limitation of the plugin. In that case it might be worth mentioning it in the README.
On the plus side it seems like you can remove the There are currently no automatic readable class names warning as it seems to be working with the latest version 🙂

System Info
System:
    OS: macOS 10.15.7
    CPU: (6) x64 Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
    Memory: 1.33 GB / 20.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 14.15.4 - /usr/local/bin/node
    Yarn: 1.22.10 - ~/.npm-global/bin/yarn
    npm: 6.14.10 - /usr/local/bin/npm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 93.0.4577.63
    Firefox: 87.0
    Safari: 14.1.2
  npmPackages:
    @vanilla-extract/vite-plugin: ^2.0.2 => 2.0.2
    vite: ^2.5.4 => 2.5.6

Ah this seems like a regression within vite: HMR works fine for vite 2.4.4 but breaks with 2.5.0.

to be more concrete the issue appeared with the second beta release: 2.5.0-beta.1.
Not too much that changed in that beta release according to the release notes, so I hope this giving you something to work from 🤞

I think https://github.com/seek-oss/vanilla-extract/issues/190 was closed with this vite update, because the weird behavior of removed styles still being present no longer occured because the page now always fully reloads.

@andrewgreenh You might be right. Will be looking into this really soon. Not sure if we can do anything to fix it or if it's purely a Vite issue at this stage though.

Just released @vanilla-extract/vite-plugin v2.1.0. It allows you to switch the style runtime from the vite one to the vanilla-extract one. Try passing devStyleRuntime: 'vanilla-extract' and let me know if the HMR experience improves. We may move to it by default if it results in a better dev experience.

First test indicates that this works flawlessly :)
Will definitely keep an eye on HMR but at the moment, I can't find any problems 🎉

Not sure if this is a similar issue, but I am working on a library that uses vanilla-extract and vite in lib mode. I cant seem to get hmr to work at all due to the following error:
ve vite-plugin: 2.1.0
ve css: 1.6.0
ve sprinkles: 1.3.0
yarn run v1.22.10
$ vite build --watch
vite v2.5.3 building for production...

watching for file changes...

build started...
✓ 74 modules transformed.
dist/fenrir-components.es.js   271.68 KiB / brotli: 23.24 KiB
dist/style.css                 152.75 KiB / brotli: 8.57 KiB
dist/fenrir-components.cjs.js   273.36 KiB / brotli: 23.25 KiB
built in 2957ms.

build started...
✓ 74 modules transformed.
[load-fallback] Could not load @rtkwlf/fenrir-react/src/components/icon-button/icon-button.css.ts.vanilla.css?hash=a5527094081c897d15b95cdffbfaa990 (imported by src/components/icon-button/icon-button.css.ts): ENOENT: no such file or directory, open<EMAIL_ADDRESS>transforming (75) src/components/navbar/navbar.tsx

Any thoughts or ideas on how to prevent this from happening? It seems Shopify polaris POC is running into the same issue (https://github.com/Shopify/foundational-design-system-proto/issues/291)

Just an FYI, Vite has released @vitejs/plugin-react which includes react-refresh and jsx transform.
It also includes the ability to add babel plugins like  @vanilla-extract/babel-plugin 😃

@rtkaaho Have you tried setting the devStyleRuntime: 'vanilla-extract' option?

@mattcompiles I have. I am still running into the same issue unfortunately :(

@rtkaaho I've pulled down the above shopify repo but didn't receive the error you mentioned. I also note that you're running a vite build which doesn't support HMR so I don't think this is related to HMR at all. Could you please open another issue with a small reproduction of the problem?

@mattcompiles Yeah I can do that.

Issue openned here: #397

With the release of v3 of the vite-plugin all known HMR issues should now be working. 🙌


Static Postcss 2.1.1

https://github.com/postcss/postcss-loader/issues/347

Deploy preview for hopeful-hamilton-4090b9 ready!
Built with commit 3e52471ac5b0d6a08ee4c16dd8b5caa6f33d2bac
https://deploy-preview-696--hopeful-hamilton-4090b9.netlify.com


Separate CI-workflows for frontend and server

Most pull requests only change one or the other, so it would make sense
to run only the required tests. When there are changes to the shared
files, both workflows will run.

Looking good, this should probably set the CI: false environment variable for the yarn build step so the warnings wont stop it from passing

Added the CI=false for frontend.
Would this also be needed for server? That has been fine so far without it.

Added the CI=false for frontend. Would this also be needed for server? That has been fine so far without it.

Lets only add later for the backend if it becomes necessary


Dependancy on libqt5core5

Hi,
When installing in Ubuntu 14.04 I've noticed it won't install as libqt5core5 no longer exists, it is now libqt5core5a.  It seems libqt5core5a doesn't 'provide' libqt5core5 either and according to some sources I've read it seems to be intentionally renamed to cause this issue.
Anyway the issue could be fixed by having your debian control file depend on either like thus...
Depends: libqt5core5 (>= 5.0.1+dfsg) | libqt5core5a (>= 5.2.1+dfsg)
Thanks :)

Yeah, came across the same issue.

Is there any word on this? I'm still having the same issue.

We dropped support for Ubuntu 14.04.
Sorry.


add prompter impl.

Codecov Report

Merging #737 into feature-spring will decrease coverage by 1.03%.
The diff coverage is 0%.

@@                 Coverage Diff                  @@
##             feature-spring     #737      +/-   ##
====================================================
- Coverage             29.93%   28.89%   -1.04%
  Complexity               96       96
====================================================
  Files                   112      113       +1
  Lines                  4032     4177     +145
  Branches                588      620      +32
====================================================
  Hits                   1207     1207
- Misses                 2731     2876     +145
  Partials                 94       94

Impacted Files
Coverage Δ
Complexity Δ

...oft/azure/maven/spring/prompt/DefaultPrompter.java
0% <0%> (ø)
0 <0> (?)

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 58b7c14...8cc0d5d. Read the comment docs.


HDFS-17098. DatanodeManager does not handle null storage type properly

Description of PR
https://issues.apache.org/jira/browse/HDFS-17098
This PR changes the comparator for the secondary sort using storage type to one that puts null first.
How was this patch tested?
(1) Set dfs.heartbeat.interval to<PHONE_NUMBER>, and dfs.namenode.read.considerStorageType to true
(2) Run test: org.apache.hadoop.hdfs.server.blockmanagement.TestSortLocatedBlock#testAviodStaleAndSlowDatanodes
Observe that NullPointerException is no longer thrown.
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 39s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
49m  0s

trunk passed

+1 :green_heart:
compile
1m 21s

trunk passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 22s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
checkstyle
1m 12s

trunk passed

+1 :green_heart:
mvnsite
1m 25s

trunk passed

+1 :green_heart:
javadoc
1m 13s

trunk passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 39s

trunk passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
3m 19s

trunk passed

+1 :green_heart:
shadedclient
44m 28s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 35s

the patch passed

+1 :green_heart:
compile
1m 39s

the patch passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 39s

the patch passed

+1 :green_heart:
compile
1m 24s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
javac
1m 24s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m 15s
/results-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs-project/hadoop-hdfs: The patch generated 7 new + 23 unchanged - 0 fixed = 30 total (was 23)

+1 :green_heart:
mvnsite
1m 35s

the patch passed

+1 :green_heart:
javadoc
1m  7s

the patch passed with JDK Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 51s

the patch passed with JDK Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

+1 :green_heart:
spotbugs
3m 39s

the patch passed

-1 :x:
shadedclient
5m 17s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 28s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

+0 :ok:
asflicense
0m 28s

ASF License check generated no output?

126m 13s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6035/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6035

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux ed812c232d2e 4.15.0-212-generic #223-Ubuntu SMP Tue May 23 13:09:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 33c13754886a3697489a9182405e47c29e5ec30b

Default Java
Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-<IP_ADDRESS>+1-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_382-8u382-ga-1~20.04.1-b05

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6035/1/testReport/

Max. process+thread count
705 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6035/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@teamconfx Would you mind to fix the checkstyle before checkin?

Close it since #6840 has merged which is the same PR.


Usability issue: long track labels hinder selection

Consider displaying only last three digits of track IDs and/or repositioning and shrinking the text.

Change to only show numeric part of trackID:
5544e2555d3c9cf1fa8dd4b5543c7f5614e49420


No module named 'gogoproto' when using pyinstaller

Prerequisites

[X] I checked the documentation and found no answer to my problem
[X] I checked the existing issues and made sure there are no similar bug reports

Category
Other
Expected Behavior
No response
Observed Behavior
I used pyinstaller to generate the exe file but when I run the file it gives me an error "No module named 'gogoproto' " while I can still run it on my source code.
Traceback (most recent call last):
  File "swap.py", line 9, in <module>
  File "PyInstaller\loader\pyimod02_importers.py", line 419, in exec_module
  File "cosmpy\aerial\client\__init__.py", line 34, in <module>
  File "PyInstaller\loader\pyimod02_importers.py", line 419, in exec_module
  File "cosmpy\aerial\client\bank.py", line 23, in <module>
  File "PyInstaller\loader\pyimod02_importers.py", line 419, in exec_module
  File "cosmpy\protos\cosmos\bank\v1beta1\tx_pb2.py", line 15, in <module>
ModuleNotFoundError: No module named 'gogoproto'
[15000] Failed to execute script 'swap' due to unhandled exception!

To Reproduce
No response
Version
0.5.0
Environment Details (Optional)
No response
Failure Logs (Optional)
No response
Additional Information (Optional)
No response

Hi @henzycuong1
Thank you for reporting this issue.
@pbukva Could you please take a look at this issue?


Updated test_basic.py

For clarity, I have enhanced the assertion messages and provided informative docstrings. These  tests concentrate on certain elements, encouraging readability and maintainability. Using pytest, the script runs without any difficulties. Every test carries out precise validations, improving understanding and debugging capacities for next development.

Did you use chatgpt for this?

Did you use chatgpt for this?

No, Not at all

Can you please guide me in depth about where I m lagging

I don't understand why you find these comments and docstrings important. For the most part you're just writing the test name with spaces instead of underscores..
Also, why add these comments to the tests? It's very simple code, and almost nobody reads it anyway.
But real problem for me is that you changed the indentation for the entire file, instead of only adding lines.

Sorry for it, I will definately take care of such thing in future.

Can I do something else inorder to merge this code ??

I'm going to try my best at a constructive comment with the assumption that the author is working to improve as an open source contributor.
This set of changes isn't adding much value to the test suite. The comment describing the commit itself doesn't make any sense. In most cases the docstrings don't add new information, although there is an argument the ones for test_start and test_no_placeholders offer improved readability, the others don't. The PR adds pytest as an import, which is used to let the file run as an executable, but it also adds an import that is otherwise unneeded. Personally, I do prefer the 4 space indentation, and I think a separate PR to normalize that over the entire repo would be a good idea, but it does mess with git blame and I don't want to start a religious war.
It seems to me that the author is mainly incentivized by having a commit rather than improving the library. There's nothing necessarily wrong with the former - I like having my name on repos too - but the latter needs to be the primary driver. I recommend thinking more about the amount of library-value added compared to the number of line changes added to the git log and that need to be reviewed by maintainers.

I'm going to try my best at a constructive comment with the assumption that the author is working to improve as an open source contributor.
This set of changes isn't adding much value to the test suite. The comment describing the commit itself doesn't make any sense. In most cases the docstrings don't add new information, although there is an argument the ones for test_start and test_no_placeholders offer improved readability, the others don't. The PR adds pytest as an import, which is used to let the file run as an executable, but it also adds an import that is otherwise unneeded. Personally, I do prefer the 4 space indentation, and I think a separate PR to normalize that over the entire repo would be a good idea, but it does mess with git blame and I don't want to start a religious war.
It seems to me that the author is mainly incentivized by having a commit rather than improving the library. There's nothing necessarily wrong with the former - I like having my name on repos too - but the latter needs to be the primary driver. I recommend thinking more about the amount of library-value added compared to the number of line changes added to the git log and that need to be reviewed by maintainers.

Thankyou so much for such a detailed description.I will necessary follow all the above instructions mentioned by you.

I'm sorry if I'm wrong, but I am getting strong LLM vibes here.

@Erotemic That's what I thought :) It's only the spelling mistakes that make me wonder.
Anyway, I just ran black over everything, so indentation fixed. No need for religious wars, we have enough of those in RL ;)


React components should be contravariant in

I would expect React components to be contra-variant in the Props type argument. That is, I'd expect the following not to produce an error
https://flow.org/try/#0JYWwDg9gTgLgBAJQKYEMDGMA0cDecYCeYScAwhOBAHZJUwAqRJAvnAGZQVwDkUqG3ANwAoYWmoBneAA0AXGQqQadRsQA8eNhAjypUYFQDmcZgD44AXnYBXKhmDUAFJu0mAlLmFxvfGNahUcGoAFgCMpjhaEMxqAPRh5sLMouJUUnAAmvLklMoMTBrs2row+kbYAEYoUPJU1iAVSFAm5lbSIkA
At the very least this should be true for stateless functional components, given that the following works without issue?
https://flow.org/try/#0JYWwDg9gTgLgBAJQKYEMDGMA0cDecYCeYScAchACYkC+cAZlBCHAORSoYsDcAUD4cTgBhJpAB2SMTAAqRJAB4AtAAVGYAM4A+OAF44qiBt3byVPmghj18ABoAuYaMuSZc+XjoQID61GBiAczhqbT06AFcxDGBLAAoPL2CASlweOHT2GHCoMTh5AAsARk0cTwhqeQB6Iu0eanNLazgATQcRcGcpWWJ3ei8fGD9A7AAjFCgHMXCQEaQoYNC4G14gA
Is there something I don't see that prevents this for class components? I'm running into difficulty typing higher-order components due to this.

This is a question I've found myself asking myself as well. I'll get back to you on this

Here's why it wouldn't work in ComponentType, using only class Components:
https://flow.org/try/#0JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoctAGxQGc64ANOJADxiQDsATR5dDAB0AYVyQu3GAB4A3gF8AfHFnl5VWgzgBNVh259ExYWPARJXGbLYAuOFwCuIAEZIoSleqrm68AIJ2AhgAJKYSUgAqAJ5gSHIeALzMFGg+8ABCgcah4uaRMXHWdo4ubok6FOSYDlwYwOZwnL4AFCJZgjlmFjDRsXK29k6u7ooANHADJcMAlCrkcHBEMA5QXHDSIhMJ1vKLSJjbaHAJyrLAmHDNRwCESY7U1LNXQmA4YHRCbHDFQ27T8rsAPSKCheQGAuAASQuAHckHAUA8IHCeI0kC0-NNxl8YRAHNRUa44DUePtgJJCQ4sNRkXBcfjUTAABbkgDWcGAMEYKEGpSgQiAA

Actually, my example isn't quite right. Going to rethink

I'm still unsure about whether or not Props can be contravariant, but if we parameterize by Config instead it definitely can be contravariant. ComponentType conflates Props/Config right now. In an upcoming change, we choose to only represent config here. This will allow the type parameter to be contravariant.


simple ListView example from readme doesnt compile

(17, 17) Error: undeclared identifier: 'gtk_tree_view_get_model'
Did a new one here  https://github.com/StefanSalewski/gintro/pull/122/commits/40d582d1c4ed54130bab550cdfe83d3feee17135

example from readme doesnt compile

From which readme? Is it from
https://github.com/StefanSalewski/gintro/blob/master/README.adoc
I don't think so.

And for me your example compiles with gintro 0.8.9 fine, with ARC and without.
So I have no idea what your issue may be.

example from readme doesnt compile

From which readme? Is it from
https://github.com/StefanSalewski/gintro/blob/master/README.adoc
I don't think so.

Yes, this issue name is the name of example:
import gintro/[glib, gobject, gtk]
import gintro/gio except ListStore

const
  LIST_ITEM = 0
  N_COLUMNS = 1

var list: TreeView

# this is copied from gtk.nim
#proc getModel*(self: TreeView): TreeModel =
#  new(result)
#  result.impl = gtk_tree_view_get_model(cast[ptr TreeView00](self.impl))

proc getListStore(self: TreeView): ListStore =
  new(result)
  result.impl = gtk_tree_view_get_model(cast[ptr TreeView00](self.impl))

proc appendItem(widget: Button; entry: Entry) =
  var
    val: Value
    iter: TreeIter
  let store = getListStore(list)
  let gtype = typeFromName("gchararray")
  discard gValueInit(val, gtype)
  gValueSetString(val, entry.text)
  store.append(iter)
  store.setValue(iter, LIST_ITEM, val)
  entry.text = ""

proc removeItem(widget: Button; selection: TreeSelection) =
  var
    ls: ListStore
    iter: TreeIter
  let store = getListStore(list)
  if not store.getIterFirst(iter):
      return
  if getSelected(selection, ls, iter):
    discard store.remove(iter)

proc onRemoveAll(widget: Button; selection: TreeSelection) =
  var
    iter: TreeIter
  let store = getListStore(list)
  if not store.getIterFirst(iter):
    return
  clear(store)

proc initList(list: TreeView) =
  let renderer = newCellRendererText()
  let column = newTreeViewColumn()
  column.title = "List Item"
  column.packStart(renderer, true)
  column.addAttribute(renderer, "text", LIST_ITEM)
  discard list.appendColumn(column)
  let gtype = typeFromName("gchararray")
  let store = newListStore(N_COLUMNS, cast[pointer]( unsafeaddr gtype)) # cast due to bug in gtk.nim
  list.setModel(store)

proc appActivate(app: Application) =
  let
    window = newApplicationWindow(app)
    sw = newScrolledWindow()
    hbox = newBox(Orientation.horizontal, 5)
    vbox = newBox(Orientation.vertical, 0)
    add = newButton("Add")
    remove = newButton("Remove")
    removeAll = newButton("Remove All")
    entry = newEntry()
  window. title = "List view"
  window.position = WindowPosition.center
  window.borderWidth = 10
  window.setSizeRequest(370, 270)
  list = newTreeView()
  sw.add(list)
  sw.setPolicy(PolicyType.automatic, PolicyType.automatic)
  sw.setShadowType(ShadowType.etchedIn)
  list.setHeadersVisible(false)
  vbox.packStart(sw, true, true, 5)
  entry.setSizeRequest(120, -1)
  hbox.packStart(add, false, true, 3)
  hbox.packStart(entry, false, true, 3)
  hbox.packStart(remove, false, true, 3)
  hbox.packStart(removeAll, false, true, 3)
  vbox.packStart(hbox, false, true, 3)
  window.add(vbox)
  initList(list)
  let selection = getSelection(list)
  connect(add, "clicked", listview.appendItem, entry)
  connect(remove, "clicked", listview.removeItem, selection)
  connect(removeAll, "clicked", listview.onRemoveAll, selection)
  showAll(window)

proc main =
  let app = newApplication("org.gtk.example")
  connect(app, "activate", appActivate)
  discard run(app)

main()

(17, 17) Error: undeclared identifier: 'gtk_tree_view_get_model'

with ARC and without.

Its not about GC.

And for me your example compiles with gintro 0.8.9 fine

My example is the new simple todo list for GTK 4.

I have no idea currently:
grep -C12 "gtk_tree_view_get_model" ~/.nimble/pkgs/gintro-0.8.9/gintro/gtk4.nim

proc gtk_tree_view_get_model(self: ptr TreeView00): ptr TreeModel00 {.
    importc, libprag.}

proc getModel*(self: TreeView): TreeModel =
  let gobj = gtk_tree_view_get_model(cast[ptr TreeView00](self.impl))
  if gobj.isNil:
    return nil
  let qdata = g_object_get_qdata(gobj, Quark)
  if qdata != nil:
    result = cast[type(result)](qdata)
    assert(result.impl == gobj)
  else:
    fnew(result, gtk4.finalizeGObject)
    result.impl = gobj
    GC_ref(result)
    discard g_object_ref_sink(result.impl)
    g_object_add_toggle_ref(result.impl, toggleNotify, addr(result[]))
    g_object_unref(result.impl)
    assert(g_object_get_qdata(result.impl, Quark) == nil)
    g_object_set_qdata(result.impl, Quark, addr(result[]))

Can you check if that proc is missing for your install for some reason?

Ah of course, gtk_tree_view_get_model() is not exported any more. It was years ago, but now we do not export the low level procs any more. Did you took the code directly from the readme file? Well I told you all in bold that you shall take the code only from the examples directory. And I really think there it is correct, as we test all the examples when we publish a releases. Well I should update the Readme too.

OK, I think we can close this. It should be clear that the code examples in the README file are for documentation purposes only, and the code from the examples directory should be used. We may update the code in the README file eventually, maybe next winter. Asciidoc allows inserting code from files directly in documents, but github does not support this currently. And generally it is easier to write documentation when we have a copy of the code example directly in the document as in an external file. But maybe we should indeed include external code when the documentation is written.

Well, all I wanted to say here is that the example from the README can be updated. I also don't really understand why there is such a spread of material. There are many examples in the README (GTK 3), in the Examples folder (GTK 3 and 4), and in the book(GTK 4).
Maybe we should get everything in order. I would suggest creating the README files in the Examples folder separately for GTK 4 and 3. Leaving the main README cleaner.

I can do it in PR if you agree


chore(publish): run npm build in ci

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


PLEASE FIX THE CRASHES!!!!!!!!!

The Blocklauncher crashes everytime when I want to get in. PLEASE FIX THE ISSUE OR I PUT 1 STAR AND TELLING TO MY FRIENDS TO DO PUT ONE STAR.  Just wait and if you want this prob fixed,

Please do not make threats.  That is one way to get your messages removed.  Blocklauncher has not been updated to work with 0.15 yet.  If you read ANYTHING on this issues list from the last 100+ comments, it is being worked on, have patience.  Now please close this issue as you are wasting everyone's time and are only making yourself look bad over making threats.  This is NOT a way to get attention to your issue or concerns.

Plz, close this report because, were spending more time dealing with reports than fixing Blocklauncher.
Thx!


🐛 Bug: pnpm workspace protocol not supported in valid-package-def

Bug Report Checklist

[X] I have tried restarting my IDE and the issue persists.
[X] I have pulled the latest main branch of the repository.
[X] I have searched for related issues and found none that matched my issue.

Overview
pnpm has a "workspace protocol" (link) that allows you to explicitly say a package lives in your current workspace. For example, in my repository I have:
{
    "@altano/tsconfig": "workspace:*",
}

which produces this error:

1:1   error  Invalid version range for dependency @altano/tsconfig: workspace:*      package-json/valid-package-def

But that's a valid version in pnpm
Thank you for making this package btw. It's great!
Additional Info
No response

Relevant: #153 -> #156.
I think we'll need to add workspace to the allowed file|npm glob. I'd say it's a bug that it's not supported yet. 😄 Accepting PRs!

@all-contributors please add @altano for bug.

🤖 Beep boop! This comment was added automatically by all-contributors-auto-action.
Not all contributions can be detected from Git & GitHub alone. Please comment any missing contribution types this bot missed.
...and of course, thank you for contributing! 💙


fix loadBalancer error not catched

What type of PR is this?
/kind bug Fixes a loadBalancer reconcile error not catched.
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:

[x] squashed commits
[x] includes documentation
[x] adds unit tests

@outscale-hmi can you review please?


Should we remove this patch as it seems to be a request from dependent products?

Should we remove this patch as it seems to be a request from dependent products?
Originally posted by @IgorTodorovskiIBM in https://github.com/ZOSOpenTools/opensslport/pull/4#discussion_r901852858

version patch removed


Proposal to Add Reference::tag Method

I propose adding a new method, Reference::tag
// before
Reference::to('tag@translation.categorySource');
Reference::to('tag@' . Yiisoft\Log\Target::class);
// after
Reference::tag('translation.categorySource');
Reference::tag(Yiisoft\Log\Target::class);

Would you like to implement?

Tags is Yii DI feature only. This proposal should be implemented in yiisoft/di.


initial support for haproxy 2.0

Description
[Describe what this change achieves]
Issues Resolved
[List any existing issues this PR resolves]
Contribution Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable

          1 Warning

:warning:
This Pull Request is probably missing tests.

  Generated by :no_entry_sign: Danger

I'm not codeowners :D


feat: support "whitelabel"

These changes make it much easier for anyone to create an app for their own token. They just need to change some variables on constants.js, texts and images.

Can you attach some screenshots here when IS_MULTI_TOKEN = false, please?

Done

Should we add a section in the QA to check all the screens (I would suggest only validate if the elements are ok, without executing any actions).

Should we add a section in the QA to check all the screens (I would suggest only validate if the elements are ok, without executing any actions).

Done

how can i change the image in  src/assets/image/logo.png
<EMAIL_ADDRESS><EMAIL_ADDRESS>?
I cant find a place where i can download my own new logo for my wallet...


[IOTDB-1992] Add  english user doc for IoTDB REST data service

Description
Hi all :
I have submitted a pull request for IOTDB-1992, please take a look.
This pull request about add  english user doc for IoTDB REST data service.
Content1 ...
Content2 ...
Content3 ...

This PR has:

[ ] been self-reviewed.

[ ] concurrent read
[ ] concurrent write
[ ] concurrent read and write

[ ] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods.
[ ] added or updated version, license, or notice information
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious
for an unfamiliar reader.
[ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold
for code coverage.
[ ] added integration tests.
[ ] been tested in a test IoTDB cluster.

Key changed/added classes (or packages if there are too many classes) in this PR

Coverage increased (+0.02%) to 67.641% when pulling f2af9bb574e7a7858d26320afc932dab01dafbd6 on WilliamSong112:add_english_user_doc_rest_data_service into 8a51c4245f24709d8629344d2b2cb051d2593759 on apache:master.


a really dumb problem that isn't your fault

hi, i have strong-armed my exported annotations for two books, and one worked great. the other failed but had some stray underscores and single or double quotes, i reckon. i'll try again once i fix a somewhat embarrassing situation.
i cannot find where in the heck i can tell my boox (note air 2) that Obsidian can open an .md (or anything else either really) and the only other Android device i have is a remote control for one of my drones, so i couldn't possibly be more confused this far from my usual flora and fauna.
i can press and hold and the open-in pops up? but then it says only my boox reader app cam open it regardless of .md or .txt extensions.
little help? 🙏 never thought i would wish for something like defaults or SwiftDefaultApps system preferences pane on macOS!

i reported this issue to onyx and they said the Obsidian app doesn't support "open in" so maybe the documentation should take that part out or something?


Update is-number to version 4.0

Maybe hold off on this one, I missed the dependency on to-regex-range. Will have to wait for micromatch/to-regex-range#4 to be merged and released.

sorry didn't see the second comment, I reviewed on my phone first.


Add support of multiline jenkins parameters in job dsl suites

In some cases it's needed to pass multiline parameter into Jenkins job using dsl.
For instance job scheduling with timezone:
TZ=US/Eastern
H 9-19 * * 1-5
As a user I'd like to have ability to pass param in suite as

to get in properly parsed for Jenkins

move to qps-pipeline: https://github.com/qaprosoft/qps-pipeline/issues/245


Create a Profiles Automator charm

Context
As part of our whole Profile creation automation objective we want as a first step to ensure we have a charm that:

Take a Profiles Management Representation (PMR) input, via a relation
Update/Remove

Profiles in the cluster, to reflect the PMR
AuthorizationPolicies/RoleBindings

The charm should then be related to integrator charms that will be responsible for looking at different sources (GitHub, PingID, EntraID etc) and converting them to PMR.
What needs to get done

Have a spec for

the edge cases of the charm, how to add/remove Profiles and AuthorizationPolicies/ClusterRolebindings
the structure of the PMR
what the library for passing the data between charms should work

Create a new repo for the profiles automation charms (both the automator and the future integrator charms)
Have a Profiles Automator charm, with integration tests
Host the code of the library

Definition of Done

There is a new repo with descriptive README
We have integration and unit tests for the charm and the library
Have an approved spec

note that the design is initially started in the spec KF107. It initially had a design of having the Profile Automator logic in one charm and then plugging different source-integrator charms to it, to separate the logic of Profile management and fetching from different sources.
After a chat with @deusebio we are also evaluating his proposal of instead:

Abstracting away the logic of updating the cluster state (Profiles) inside of a python (charm) library
Having charms like github-profiles-automator and entraid-profiles-automator that handle the logic of talking to a source, but then use the same library for manipulating the cluster's state

We'll do a more thorough analysis of the above, with pros and cons, as part of finalising the above spec.


Publishing to directory /bin/staticsites/ss-oryx/app... takes > 10 minutes

Describe the bug
When publishing a Blazor WebAssembly (WASM) application to Static Web App, the step Publishing to directory /bin/staticsites/ss-oryx/app... takes 800s+ ... is there any way to speed this up? It is burning up valuable GitHub runner minutes.
To Reproduce

Create Static Web App via Azure Portal
Connect it to GitHub Blazor project
Run GitHub Action

Using the exact generated .yaml file with no modifications other than what was automatically done through the Azure Portal configuration.
Expected behavior
This should take only a few seconds or couple of minutes maximum.
Screenshots

For reference, running a second time is also very long ~12m

For reference, I did the exact same thing with a sample project and it only took 85s. What is happening at this step that could be taking a long time?

Is it the file size of the project?
Could it be the quantity of warnings generated by the build process?
What is actually happening at this step? I turned on debug logging, but it doesn't log any extra logs for this step to be able to see what is happening. Is there any other way to dig deeper to figure out what I need to modify in my project to make it as fast as the sample project?

Seems that running dotnet publish -c Release locally also takes a ridiculous amount of time. Going to close and circle back if I can prove this is actually related to Static Web App


Progress halt with a certain future composition on the grammers-client API user side

This is a very peculiar issue, but fortunately I have managed to come up with an relatively small example that reproduces this bug: https://github.com/MOZGIII/grammers-halt
The issue manifests with this:

If the code was working as intended, the log line main::reconciler: before iter next should've been followed by something else - either an error, or main::reconciler: after iter next; however the code stalls and does not progress.
My investigation showed:

There are no blocking locks held by any threads that would block the further execution, and also there are no async locks held besides the one lock on the grammers_mtsender::Sender by the grammers_client::Client call of next_raw_update call under the hood - which is intended; in other words this is not deadlock in a general sense.
Tested this via tokio console from async and lldb for sync mutexes.

The issue is not with tokio::sync::Mutex specifically, since I have tried swapping the mutex implementation in question with async_mutex::Mutex and got the same outcome - the app stalled.

The select chain at https://github.com/Lonami/grammers/blob/724188fd4c95a835308cdca051cee4e96e012f21/lib/grammers-mtsender/src/lib.rs#L333-L338 does not progress, despite the conditions for the progression of the individual futures being fulfilled; I do not mean the select is the issue here, because it seems that the reason they do not progress is because the whole task doesn't get scheduled - i.e. the futures (or, rather, the combined select future) do not progress because are not polled, meaning the task is simply not schedule - not because the futures are polled but are stuck.
I have managed to test this by trying this code here:

Screenshot of the code here.

Sorry for the screenshot, didn't commit it, and this is all I got now.

I wrapped the
https://github.com/Lonami/grammers/blob/724188fd4c95a835308cdca051cee4e96e012f21/lib/grammers-mtsender/src/lib.rs#L321
with tokio::spawn and added logging inside that spawned future after the sleep returns; then made the select wait on JoinHandle of that spawned task. After a minute, I saw the log message - which means that timer worked - but select that was polling on the JoinHandle didn't return - which means that the task that executes select was not scheduled upon JoinHandle returning.
Rather odd, yet maybe I'm missing something.

I don't know what's going on there, but I suspect a tokio bug.

I have managed to create a workaround - essentially the same logic but executed with two independent spawned tasks instead of structured concurrency, it can be found at https://github.com/MOZGIII/grammers-halt/tree/working1.
See https://github.com/MOZGIII/grammers-halt/compare/master...working1 for the changes that make the code work - does not solve the issue, but at least might be useful for someone who needs to work around this bug in the meantime.

The root cause has been boiled down to how locking inside of the invoke interacts with the locking at next_raw_update in a situation where, like we have in the example, we select the next_raw_update together with something else (in our case a timer) and inside that other select branch we do the invoke.
That leads to a deadlock, where invoke tries to lock on the sender mutex, and waits infinitely; normally this wouldn't be a problem as the current holder of the lock would make progress and relieve the invoke from needing to acquire the lock on sender by just returning the result - however our this case, the sender is locked by next_raw_update, and we are not in a select statement (macro) itself, but in a select branch - meaning that next_raw_update future is not polled anymore, despite actually being ready to progress. This is the ultimate reason why the sender.step isn't being polled, and why the sender can't make progress; couple that together with a lock on sender at invoke - and we get a deadlock.
Note that if invoke wouldn't try to lock on sender and would just wait for rx to get ready we'd still get the same deadlock, since the current sender driving future can't progress.
There are no issues with tokio - well, really, as expected - in fact, it can't do anything at that point because the composed future state machine simply does not allow to poll on that sender.send code branch.
I'd argue that grammers-client implementation should be altered to make it impossible to get in a situation where the client can't progress - especially since it was clearly designed to allow the progress to be made in this kind of a situation - meaning I'd consider this a bug.

@Lonami how are you willing to proceed? I can work on a fix for this when I get back to it - but at the moment I'm busy elsewhere.

I still need enough brain power to read through and truly understand the problem. I don't know when that'll be.
I'm not under any time pressure to see this fixed. So if you have a clear path forward on your mind, that'd be best.


Interval support

Summary of the changes / Why this improves CrateDB
Checklist

[ ] User relevant changes are recorded in CHANGES.txt
[ ] Touched code is covered by tests
[ ] Documentation has been updated if necessary
[ ] CLA is signed
[ ] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

It overwrote the doc introduced with https://github.com/crate/crate/pull/8920.
The interval branch was supposed to be a feature branch.

It overwrote the interval literal documentation pr #8920 that was merged to the interval branch. The interval branch was supposed to be a feature branch.

My bad, i didn't get that. I will fix it.

moved to https://github.com/crate/crate/pull/8927


update changelog for v0.8.0

Signed-off-by: Steve Kriss<EMAIL_ADDRESS>Add changelog entry for v0.8.0 along with upgrade instructions from v0.7.1

Fixed kc in changelog. Rejiggered roadmap.

updated links.

@ncdc any comments before we merge?

Alright, just ran through another test on a fresh AWS cluster for the 0.7.1->0.8.0 upgrade, looks good. @nrb can you merge if lgty?


String Concatenation

Add support for long chains of string concatenation using the + operator by generating efficient bytecode using StringBuilder.

Replaced with Format Strings.


Add get and post functions akin to python requests module

Hey there.
I appreciate the work that's been put in so far by puppy.
I think nimlang forcing you to ship external DLLs for SSL support is kind of whack...
puppy not requiring extra compile time flags is a win too.
I think there is an opportunity for an improved user experience regarding making requests via puppy.
I think having get and post functions would be a good start. Could you implement all the verbs? maybe... but those two are essential.
It would help reduce friction for sending data for newcomers to nm.
I wasn't smart enough to figure out how to have generic headers that can be overridden like in python.
I heard there was an Option[T] but I'm not sure how that works.

Hello and thanks for the suggestion and PR. Sorry we were slow to reply here but in the end I found this to be a good idea and was able to get this into Puppy's latest 2.0 release.
Puppy had changed a bit between when you drafted this PR and today so I did have to implement things in the updated Puppy. In the end what matters is the new and nice API is available.


No longer working on v64

The shrouds spawning code has been removed in v64

The shrouds spawning code has been removed in v64

Pair it with YesFox and it will work, just make sure to change certain settings for compatibility

I will list the things that don't work properly anymore, Bringing Back Vain Shrouds won't do anything as the code was deleted, when paired with YesFox now in V64 the relocation and removal settings prevent Vain Shrouds from spawning for the host but they spawn for clients causing a desync. Fix False Vain Shroud Removal and Cap Vain Shroud Iterations should still work theoretically

Actually there may be some shenanigans going on, we got a very nasty desync earlier where only I could see the fox. Still waiting to find out if this is an issue with this mod, will update my comment when I know more

Might be easier for you to use YesFox as a dependency instead of re implementing all the code removed in v64 and make the relocation/removal options work with it


Deletion II: clean removal process for Kyma (CR removal, no finalisers dropped etc.)

Description
The deletion of Kyma has to happen in multiple steps of following sequence:

Cleanup Reconciler: Remove CRs
Component Reconcilers: delete components by manifest /execute custom deletion actions
Base Reconciler: delete CRDs
Cleanup Reconciler: delete resources by labels
Cleanup Reconciler: remove namespaces: if they don't get deleted after a timeout, remove finalisers and enforce deletion of namespace

AC:

Deletion of Kyma happens by following a clean removal approach (drop CRs -> drop resources -> drop CRDs/namespaces) without having a need to remove finalisers from namespaces
Installation of Kyma on a cluster which had previously Kyma installed works without issues

Reasons
Support clean Kyma removal / deletion process.
Attachments

Functionalities of the Reconciler were migrated to the new architecture, this issue will not be worked on.


refactor: runtime takes no dependencies on capabilities

I have to admit that this is a relative large PR and apologize beforehand. It refactors the core of slight - the runtime crate to not depend directly on any of the slight capabilities, including slight-kv, slight-mq, etc. This comes at a cost though. The slight CLI implementation now needs to know how to constrct a capability service before adding it to the slight runtime builder, which is a acceptable compromise.
In addition to the runtime refactoring, this PR also cleans up some redudent code in slight capabilities. Particularly, this PR removed capability-state.
Signed-off-by: Jiaxiao Zhou<EMAIL_ADDRESS>

@Mossaka: I'd like to know what the perf difference is at startup. When you say there's a tradeoff, I wanna know what it is....

@Mossaka: I'd like to know what the perf difference is at startup. When you say there's a tradeoff, I wanna know what it is....

I believe the tradeoff is not runtime impacting, but rather code design impacting. It makes the CLI need to know a bit more about the capabilities. I believe this is a preferable tradeoff when weighed against the runtime needing to know details about the capabilities.

OK, perfect. I saw the internal chatting after commenting. Sounds great to me!


Ventura nudge detection issue

Hi Team , i observed that having issue with nudge , unnecessarily users are getting error message as like below.
Issue observed it like - user is having 12.5.1 and nudge defined that 12.6.1 to update so that user in part of the rule like Nudge is active & running mode.
so when part of that group of users after upgraded to ventura those are getting below error. I think nudge is not identifying  that current OS either to run or not and ventura is already excluded from that ventura group.(suspect after upgraded to ventura that device is not connected to internet or taking some time to connect and still there that configuration profile so that device is getting triggered that nudge with error.)
Also i would like to hide that app from application folder and also from Launchpad ( it unnecessary to show it to users and they started questioning )

@mani2care:
Please confirm you've removed the quarantine flag before uploading:
ls -lah@ /path/to/Nudge.pkg
(We've added a rq to our ~/.zshrc.)
You're welcome to adapt the following to hide Nudge:
https://github.com/dan-snelson/Nudge-Post-install/blob/main/Nudge-Post-install.bash#L151-L164

If I use this instruction com.apple.quarantine  issue will be resolved? So the ventura users will not get this error who are from Monterey to ventura?
Is this not added /validated via nudge? Or is there any fixes or solution or suggestions
https://derflounder.wordpress.com/2012/11/20/clearing-the-quarantine-extended-attribute-from-downloaded-applications/

For some reason I thought removing the quarantine flag shouldn't be needed if the app is recognized by Apple? If the flag has to be removed, thought also record of it is stored locally? I could be wrong.


Survey Question on the For loop in source file https:/github.com/DiTo97/gol/blob/master/src/cpu/gol.c line 151

Hello Sir/ Madam
We are from a research group at Iowa State University, USA. We want to do a survey on Github developers on the methods they used for paralleling their code. To do the survey, We want to ask three questions about this for loop:
Can you briefly explain the purpose of using pragma for this case? If the pragma contained reduction and private clauses, can you briefly mention the purposes of variables in those clauses?
How much confidence do you have about the correctness of this implementation? You can choose from 1-5 with 1 as the lowest confidence score and 5 as the highest confidence score.
(Optional) Do you actually run (interpret the code with compilation and pass input/get output) the code and see the optimization of parallelization? Yes/No
If yes, can you provide the information of what are the input and expected output of this program (the input that caused the program to run through this for-loop).
The for loop is from line 151 of file https:/github.com/DiTo97/gol/blob/master/src/cpu/gol.c
Here is a part of the code:
#pragma omp parallel for
#endif
for (i = 0; i < life->nrows; i++) {
free(life->grid[i]);
free(life->next_grid[i]);
}

Hi,
I'm glad to help you with your survey. This program was designed as a research case study to compare the performance of large-scale Conway's Game of Life under different parallelization settings: single-thread, multi-thread with Open MP, multi-process with MPI, hybrid with Open MP+MPI and on CUDA. The program would take a text file as input specifying the size of the board, and the initial configuration of alive cells.
The specific piece of code you are referring to is called near the end of the program during cleanup ops. It takes a life_t object as input (you can find its definition in life.h) and frees up the memory allocated on a single processor for a subset or the full GoL grid depending on its size. The grid (or part of it) and its copy (necessary for update and swap ops at the end of each iteration) are allocated dynamically as 2D pointers at startup. Therefore the pointers can be freed up independently, i.e., in parallel, if multi-threading is enabled. So, we just check if the code is compiled with Open MP through the macro guard, and if that's the case we define a #pragma guard to parallelize the underlying for-loop with Open MP. The function doesn't provide any outputs.
About my confidence in the correctness of the implementation of the function, I would rate it as full a 5 out of 5, because we have tested it thoroughly, and we have noticed a noticeable speedup with Open MP enabled. I would rate the whole program as a 4 out of 5, because we did not provide a 100% test coverage due to time constraints on our deadline.
Finally, we have observed the effect of any possibile optimization routines in the code, included this specific function. You can find an in-depth analysis in the report folder.
Hope this helps with the survey!

Thank you so much! It was really helpful. I am closing the issue. Thank you again!


Visually retaining selection after blur

How would you recommend visually retaining the text selection even when the editor is blurred? My initial thought was to use inline styles but I'd like to get a second opinion.
See the example below. I'd like the selection to still show when changing text properties from an input.

Awesome screenshots. This looks really nice.
Since the browser can't maintain both cursor positions simultaneously, there's no native solution for this. In Notes, I have tried two different approaches:

What you have here, which just moves the selection over to the flyout. Here, one would just hope that the user isn't too thrown off by the selection disappearing. This is what is currently in production on Notes. I basically punted on it since people didn't seem too confused when using it.

My initial approach, which I replaced with the option above. Create a "fake" entity, either a "LINK_PLACEHOLDER" (or something like that) or a "LINK" with an empty href. In your decorator component, then you would check whether it's a fake link, and decorate it in some way to indicate that it is the target text. If you accept the link entry, replace the entity or merge in the data with the new href. If you reject the link entry, you'd just set the entity back to null on that range.

Inline styles could work there too. You'd just remove the style after accepting or canceling the link entry.


Update the poodle config site file to use the 3.4.2 libraries.

Description
I updated the poodle config site file to use the 3.4.2 libraries.
Type of change

[X] Other - config site file update to use newer libraries.

How Has This Been Tested?
I used the new config site file to build VisIt on poodle. I then tested the resulting build by launching the GUI and creating a pseudocolor plot.
Reminders:

Please follow the style guidelines of this project.
Please perform a self-review of your code before submitting a PR and asking others to review it.
Please assign reviewers (see VisIt's PR procedures for more information).

Checklist:

[ ] I have commented my code where applicable.
[ ] I have updated the release notes.
[ ] I have made corresponding changes to the documentation.
[ ] I have added debugging support to my changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have confirmed new and existing unit tests pass locally with my changes.
[ ] I have added new baselines for any new tests to the repo.
[ ] I have NOT made any changes to protocol or public interfaces in an RC branch.

Is conduit the only TPL version change we need?

I changed Uintah to version 2.6.3 two weeks ago,, but I don't know if that's in your current 3.4.2 TPL builds. Shouldn't affect any testing results.
There were new VTK patches added in August that will be needed for the release, but no version change.

I just checked the 3.4.2 install and it has Uintah 2.6.2. I agree, it shouldn't affect the test suite results.