In debug it works but in production the alert box does not appear on Android

I have this abnormal problem. When I compile the application in debug mode everything works in the correct mode. The moment I create the apk and publish it for online tests, the alert to activate the GPS no longer appears. Anyone know what it is?
Here the specifications:
  React Native Environment Info:
    System:
      OS: macOS 10.15.4
      CPU: (4) x64 Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
      Memory: 74.91 MB / 8.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 13.8.0 - /usr/local/bin/node
      Yarn: 1.22.0 - ~/.yarn/bin/yarn
      npm: 6.13.7 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    IDEs:
      Android Studio: 3.6 AI-192.7<IP_ADDRESS>92135
      Xcode: 11.3.1/11C505 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.6.3 => 16.6.3
      react-native: 0.59.8 => 0.59.8
    npmGlobalPackages:
      react-native-cli: 2.0.1
      react-native: 0.61.5

I thank in advance who will want to help me.

Thanks for the issue, I will check it asap.

Same for me:
System:
OS: macOS 10.15.6
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Memory: 631.12 MB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 12.16.1 - /usr/local/bin/node
Yarn: 1.22.4 - /usr/local/bin/yarn
npm: 6.14.6 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
Android SDK:
API Levels: 23, 25, 28, 29, 30
Build Tools: 28.0.3, 29.0.2, 29.0.3
System Images: android-22 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom, android-25 | Google APIs Intel x86 Atom, android-26 | Google Play Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom_64, android-28 | Google Play Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom
IDEs:
Android Studio: 4.0 AI-193.69<IP_ADDRESS>26763
Xcode: /undefined - /usr/bin/xcodebuild
npmPackages:
react: ^16.13.1 => 16.13.1
react-native: ^0.62.2 => 0.62.2
npmGlobalPackages:
react-native: 0.61.5

https://github.com/Richou/react-native-android-location-enabler/issues/43

check this out: https://github.com/facebook/react-native/issues/10009#issuecomment-347839488
try setTimeout or a delay function before trying to access the Android API.
const delay = ms => new Promise(res => setTimeout(res, ms));
await delay(5000);


Support sending of private transactions

Component
Cast
Describe the feature you would like
I'll like to use the following parameters in the cast send API, on top of parameters like value, nonce:

privateFrom
privateFor
privacyGroupId

It'll be great to be able to use these extra options.
Additional context
This is used in both HyperLedger Besu and GoQuorum.
https://besu.hyperledger.org/en/stable/private-networks/concepts/privacy/private-transactions/

It would be great if these options could be added to forge script as well.

this would mean we'd need to add a serde flattened other: HashMap to the Transaction type, similar to what we did with for Block
https://github.com/gakonst/ethers-rs/blob/b71e6ad00b2290e103342a2c7fe20d01865e0ba7/ethers-core/src/types/block.rs#L102-L103
I don't think this would add too much friction since most of the TX types use builder pattern, wdyt @gakonst?


Throws exception for very large JSON numbers

Whenever I use Decode.fromString, I expect it to return either Ok or Error and never throw exceptions.
However, if the JSON contains a really large number, a System.InvalidCastException exception is thrown.
The various int decoders do have bounds checking, and that works to some extent. But if the number is too crazy large, even the bounds check don’t help.
If this is a problem with how Newtonsoft does things, maybe add a try-with in Thoth.Json.Net?
❯ dotnet fsi

Microsoft (R) F# Interactive version <IP_ADDRESS> for F# 7.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> #r "nuget: Thoth.Json.Net, 11.0.0";;
[Loading /Users/simon/.packagemanagement/nuget/Cache/2fd0b2ac9e4082b4ba06da12786fc9dc357957f471b12f92af911c26d54f0284.fsx]
module FSI_0002.
       2fd0b2ac9e4082b4ba06da12786fc9dc357957f471b12f92af911c26d54f0284

> open Thoth.Json.Net;;

-- int fails:
> Decode.fromString Decode.int "9999999999999999999";;
System.InvalidCastException: Object must implement IConvertible.
   at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
   at Newtonsoft.Json.Linq.Extensions.Convert[T,U](T token)
   at Newtonsoft.Json.Linq.Extensions.Value[T,U](IEnumerable`1 value)
   at Newtonsoft.Json.Linq.Extensions.Value[U](IEnumerable`1 value)
   at Thoth.Json.Net.Decode.int@261.Invoke(String path, JToken value)
   at Thoth.Json.Net.Decode.fromValue[T](String path, FSharpFunc`2 decoder, JToken value)
   at Thoth.Json.Net.Decode.fromString[T](FSharpFunc`2 decoder, String value)
   at <StartupCode$FSI_0004>.$FSI_0004.main@() in /Users/simon/tmp/stdin:line 4
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
Stopped due to error

-- Let’s try int64 instead. Also fails:
> Decode.fromString Decode.int64 "9999999999999999999";;
System.InvalidCastException: Object must implement IConvertible.
   at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
   at Newtonsoft.Json.Linq.Extensions.Convert[T,U](T token)
   at Newtonsoft.Json.Linq.Extensions.Value[T,U](IEnumerable`1 value)
   at Newtonsoft.Json.Linq.Extensions.Value[U](IEnumerable`1 value)
   at Thoth.Json.Net.Decode.int64@277.Invoke(String path, JToken value)
   at Thoth.Json.Net.Decode.fromValue[T](String path, FSharpFunc`2 decoder, JToken value)
   at Thoth.Json.Net.Decode.fromString[T](FSharpFunc`2 decoder, String value)
   at <StartupCode$FSI_0005>.$FSI_0005.main@() in /Users/simon/tmp/stdin:line 5
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
Stopped due to error

-- Removing one `9`, it’s a valid in64:
> Decode.fromString Decode.int64 "999999999999999999";;
val it: Result<int64,string> = Ok<PHONE_NUMBER>000000000L

-- And then, when using just int the bounds check works:
> Decode.fromString Decode.int "999999999999999999";;
val it: Result<int,string> =
  Error
    "Error at: `$`
Expecting an int but instead got:<PHONE_NUMBER>99999999
Reason: Value was either too large or too small for an int"

I suspect the problem is because of this line:
https://github.com/thoth-org/Thoth.Json.Net/blob/dde35518f9eda3c5d35b39dd97945892e4435018/src/Decode.fs#L213C21-L213C21
We are accessing the value as a float because it allows for big numbers (I think) and do the check after if the number is inside of the correct range.
We could change that to use float32 but this would probably just delay the problem. We can try using a try ... with.
As a note for my self, in the Thoth.Json.Core version of the library the exception will be different depending on the language so I need to think of a way to unify them.


[Flaky test] Unit test for pkg/scheduler/preemption fails

/kind flake

What happened:
Flaky unit test for pkg/scheduler/preemption TestPreemption/preempt_newer_workloads_with_the_same_priority.
=== Failed
=== FAIL: pkg/scheduler/preemption TestPreemption/preempt_newer_workloads_with_the_same_priority (0.10s)
    preemption_test.go:1467: Issued preemptions (-want,+got):
          sets.Set[string](
        - 	{"/wl2:InClusterQueue": {}},
        + 	{"/wl3:InClusterQueue": {}},
          )
=== FAIL: pkg/scheduler/preemption TestPreemption (3.38s)

What you expected to happen:
It never happened.
How to reproduce it (as minimally and precisely as possible):
https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kueue/2875/pull-kueue-test-unit-main/1826529623073099776
Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version):
Kueue version (use git describe --tags --dirty --always):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/assign


Delay if attemptCount is present

@geneh,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


[Relax] Allow out_sinfo to be omitted from R.call_tir

Prior to this commit, the Relax type produced by calling a TIR PrimFunc needed to be explicitly specified using the out_sinfo argument.  These output shapes are required in order to allocate output tensors during the CallTIRRewrite lowering pass.  However, specifying them explicitly, especially in hand-written functions, duplicates information that is already present in the PrimFunc signature, and introduces the potential for inconsistencies.
This commit updates the MakeCallTIR function to infer out_sinfo if not explicitly specified.  This inference uses the number of relax arguments to identify output parameters in the signature of the PrimFunc, which then become the return values from R.call_tir.  Currently, this inference of out_sinfo occurs when constructing the relax::Call object, after which the out_sinfo is always present in the Relax IR.

Just want to note that it is not always possible to do such inference.
class IRModule:
    @T.prim_func
    def reshape(A : Buffer((2, 4)), B: Buffer((n, m)):

    def main(A: Buffer((2, 4))):
         lv0 = R.call_tir(reshape, [A], R.Tensor((1, 8)))

For example, the above code is a valid tir call, but needs the output sinfo to be explicitly specified. Because we have such cases, and call_tir is a lower level function, it is safer to always ask for sinfo, but checks its consistency with the corresponding prim_func signature if needed

For example, the above code is a valid tir call, but needs the output sinfo to be explicitly specified. Because we have such cases, and call_tir is a lower level function, it is safer to always ask for sinfo, but checks its consistency with the corresponding prim_func signature if needed

That's a good point, and I agree that we should always be able to explicitly specify the output struct info, as output tensor shapes in TIR may define symbolic shapes.  However, I don't think it should a required argument.
I've added a new test case, based on your example with reshape, to validate the behavior when the output shape cannot be inferred.  While the initial implementation did identify this failure and throw an error, the error message wasn't ideal.  I've added an earlier check for non-inferable output shapes, so that the error message can direct the user to provide the out_sinfo field.
Does the udpated check/error messages address your concerns for this PR?

I think this is mainly a design consideration here on what do we view the intended use of CreateCallTIR, in terms of different expectations we have on caller of the function. I can see some merits on auto deduction or call for explicitness
Given call_tir is lower level, having "less automation" here during pass and have explicitly checking would ensure correctness while indeed asking pass writers to do a bit more. It is like explicitly annotating types when writing c++ code versus writing auto. I think encouraging pass writers to explicitly think about the DPS pattern and always provide the return argument helps to reduce uncertainty here. While I can indeed see some merits of automated decusion, given it is not always possible, I still prefer we have the explicitness and provide good amount of consistency checking

I think encouraging pass writers to explicitly think about the DPS pattern and always provide the return argument helps to reduce uncertainty here.

While I think this would be an interesting point to discuss, I don't think it's relevant to this specific change.  This PR keeps the exact same out_sinfo in the C++ IR types, and still requires pass writers to explicitly provide the output info.  The MakeCallTIR function is not exposed to the back-end C++ API, only through the front-end Python API.
This change is solely in the front-end, for cases where an IRModule is being hand-written.  I'd like to make that use-case less error-prone.

Having such explicit argument makes the "intent" clear, with the explicit sinfo, we can write down the semantics in a clear fashion

Good point on the semantics.  This change would add an additional step to the user-facing semantics of R.call_tir.
def call_tir(func, args, out_sinfo):
    if out_sinfo is None:
        out_sinfo = infer_out_sinfo(func, args) # may throw

    out = alloc_outputs(out_sinfo)
    func(*args, unpack_outputs(out))
    return out

I suppose that I'm getting stuck on is the "intent" part.  While there are exceptions, in the majority of cases, there's one and only one correct value for out_sinfo.  Since the user doesn't have any choice in it, we can't infer any intention from the user about it.  On the other hand, if the user has the option of omitting the out_sinfo, then we could distinguish between the intent of "use whichever output is valid" (e.g. R.call_tir(unary_abs, [x])) and "verify and use the output I expect" (e.g. R.call_tir(unary_abs, [x], R.Tensor([16],'float16'))).

In this particular case, having good well form check about consistency would help a lot toward that direction

Agreed.  I think for now, let's put this PR on hold, and I'll update the well-formed checker to verify consistent between the R.call_tir callee and the input/output arguments.  (Since that's a change that we both agree on, and covers many of the same error modes.)

closed in favor of #17285


Rule amendment -  Remove role abandonment aHelp requirement.

About the PR
Role abandonment rule.
Why / Balance
Currently there is a requirement for aHelp if you are going to leave the game. In the past we would sometimes open another slot for this but now with cryosleep it is irrelevant and just pointless noise and aHelp volume in the aHelp relay we currently don't need.
Technical details
Just rule text edit.
Media
NA
Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes
NA
Changelog
NA

Important jobs/roles like nukies and AI can't really "cryosleep" though

Important jobs/roles like nukies and AI can't really "cryosleep" though

Sounds like a easy mechanical/mapping issue to be fixed.

This datafield should be set to false for all command job prototypes to remove the
You are playing a job that is important for Game Progression. If you have to disconnect, please notify the admins via ahelp.
message in the chat at roundstart.

For the record: Count me fixing up this for merging into stable as my approval per the hotfix procedure


No auto-complete for types in third party jars that have no usages (yet)

I'm fairly new to Bazel but something I'm having issues with is a lack of auto-complete for types in jars that are defined (via bazel-deps), dependend on (via java_library(deps=[...])), but aren't currently used anywhere in my projects java files. For example when adding a brand new jar to the project.
The problem I'm seeing is that until I manually write an import some.Type; in one of my java files and sync the project, IntelliJ doesn't seem to be aware that the library dependency exists at all:

Doesn't show up in External Libraries
No auto-complete of the package during writing an import statement
No auto-complete of types in the library
No find class/file/etc for symbols that exist in that jar

Manually adding the import statement and using the library types without auto-complete compiles/runs fine which indicates to me that there's no issue with my usage of bazel.
Versions
Plugin: v2<IP_ADDRESS>.2
Build label: 0.22.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Jan 28 12:59:27 2019<PHONE_NUMBER>)
Build timestamp:<PHONE_NUMBER>
Build timestamp as int:<PHONE_NUMBER>
IntelliJ IDEA 2018.3.4 (Ultimate Edition)
Build #IU-183.5429.30, built on January 29, 2019
JRE: 1.8.0_152-release-1343-b26 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

More broadly, auto-completing any external/ workspaces would be supremely helpful.  Maybe I am doing something wrong, but I don't get auto-complete for even external workspace targets/packages even when there are usages.

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.


L1 Transaction Youkai token shows the capacity of other tokens

Describe the bug
L1 Transaction Youkai token shows the capacity of other tokens
Steps to reproduce the behavior:
1.See the following figure for details

Fixed


Fix for Issue #130

Fix for Issue #130
In 'The Basics' section of the website, the printed text used to exceed the screen limit instead of going to next line. This is now fixed by using word-wrap.
Here is the screenshot of how it looks after the fix:

p.

Landed already as e2d9f01b6c407f886ca66bb1b8c89888fb24b778 sorry


DSX Global

DSX Exchage is going to migrate to new API very soon. Old API going to be stopped.
Announcement text:
Hi ,
We previously emailed you about a big change coming to DSX. This will take place on March, 25th and will take a whole day, so that our team can make sure migration is completed successfully.
You will need to make sure that your active orders are either cancelled or completed by the time we start migrating to a new platform and perform routine maintenance.
After the migration is completed, our mobile app will not be immediately available. However, we will do our best to restore it as soon as we can.
After the upgrade is completed, our current API will be changed. Please take appropriate measures to get prepared so it doesn’t interrupt your trading. Our new API documentation you can find here (https://api.dsxglobal.com/). You will also need to create new API keys to access a new API.
Your account will be assigned new crypto addresses for making deposits to DSX. Please use those new addresses, as your old ones will no longer be supported.
Once the upgrade is complete, we’ll send you another email with instructions on how to access the new and improved DSX.
Thank you for your patience.
Best regards,
The DSX Team
#3468

please do not introduce a v2 package
just do everything in org.knowm.xchange.dsx

@walec51 you are right, but I accepted the PR anyway. Thanks as always for your comments and efforts!!!!

ok I'll change the package in a separate PR
@pchertalev I know the exchanges API version changed but that does not mean that we have to break applications that use generic interfaces and just want to
ExchangeFactory.INSTANCE.createExchange(DsxExchange.class);

but cannot because DsxExchange package changes
on some exchanges we even use a mixture of V1 and V2 APIs but the package of Exchange and Service classes does not change, version migrations are transparent to our users that use generic interfaces

@walec51 Thanks!

https://github.com/knowm/XChange/pull/3470


Options buttons grayed out for all plugins

Brief description of your issue
Hey, I'm a bit confused regarding the plugins' functionality, and I don't know if it's a bug or I'm supposed to take extra steps to activate some option or whatever. There's no available information about it.
I started by trying to figure out how to enable the VirusTotal scanning functionality, and looking at other users' UIs, apparently I don't even have the relevant section in the Options window at all, since from what I understand, there should be an OnlineChecks option below NetworkTools?:

Looking further in the Plugins option, it seems like they're all activated (or at least none are disabled), but when I try to open their options, every single Options... button is grayed out, for every plugin:

I have activated the Enable plugins option amongst others, but it doesn't seem to help:

I apologize if this isn't a bug, but I wasn't able to find any related info about it.
Steps to reproduce (optional)
No response
Expected behavior (optional)
Mostly to be able to activate VirusTotal online scanning, but also figure out if the various plugins have options I can change.
Actual behavior (optional)
No response
Environment (optional)
System Informer 3.1.24298.0 Release (running as Administrator)

Windows 11 Pro [Version 23H2 / OS build 22631.4541]

Try going to Options -> Advanced -> EnableDefaultSafePlugins and change the value to 0 from 1 and see if it makes a difference or not.

there should be an OnlineChecks option below NetworkTools?:

The page was removed because OnlineChecks only had one option and an entire settings page didn't make sense.

ooking further in the Plugins option, it seems like they're all activated (or at least none are disabled), but when I try to open their options, every single Options... button is grayed out, for every plugin:

Plugin settings are integrated into the UI.
The options button is only for backwards compatibility with legacy plugins from 5-10 yeas ago. They didn't have settings integration and that was the only method to access those settings at the time.
For example the original settings window:

The settings button was the only method to access plugin settings:


DynamoDB Support for BillingMode

DynamoDB now supports billing modes for on-demand pricing (yey 😄 )
https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BillingModeSummary.html
Would be awesome if we could get it included in @aws-cdk/aws-dynamodb, I could have a stab at doing a PR but im not sure if you guys dont just have an automatic API builder or something?

Hmm the plot thickens, it seems like "billingMode" is available according to the docs<EMAIL_ADDRESS>But I cant work out how you are supposed to access / set it (Typescript v 0.19.0)

What you're seeing is that the billing mode is available at the (autogenerated) L1 level, but not yet at the (hand-written) L2 level, with a nice shiny API.
We'll happily accept a patch if you feel like making one. Otherwise, I suggest you add overrides at the lower level to unblock yourself we have support at a higher level.


Depreciation on Mobile view

In production, the side menu in the mobile view has desapeared :

Click on profile pic to reproduce

The sidebar has been removed in https://github.com/Zenika/skillZ/pull/501


Ghost field added to FHIR mockdoc, which gets duplicated @ XML attribute prefix as it reloads

It's entering here
https://github.com/atlasmap/atlasmap/blob/4f8901fd59b4a374c829168a89304490ffa45860/ui/src/app/lib/atlasmap-data-mapper/utils/mapping-util.ts#L94
which means this doesn't return proper field
https://github.com/atlasmap/atlasmap/blob/4f8901fd59b4a374c829168a89304490ffa45860/ui/src/app/lib/atlasmap-data-mapper/utils/mapping-util.ts#L80
So my guess is that the mapping deserialization is happening before document definition is completely built.

TLDR I put this on hold until React migration is settled.
This fetchDocuments() is async work
https://github.com/atlasmap/atlasmap/blob/c9977f167d3926be913457e342f3ea896e084173/ui/src/app/lib/atlasmap-data-mapper/services/initialization.service.ts#L203
And it's possible that this fetchMappings() starts to deserialize mappings before document initialization by fetchDocuments() is completed.
I thought we can subscribe initializationStatusChanged$ and wait for ConfigModel.initCfg.initialized comes to true, but then it doesn't happen until field action service is initialized.
https://github.com/atlasmap/atlasmap/blob/c9977f167d3926be913457e342f3ea896e084173/ui/src/app/lib/atlasmap-data-mapper/services/initialization.service.ts#L534
The field action service initialization is delayed on purpose to wait for custom field actions to be loaded when .adm is uploaded. We have to untangle this initialization statuses, basically in following order:

library upload and classpath refresh should happen first, then
document initialization
field action service
mappings

A good news is that, this is standalone only issue, as in Syndesis mapping definition is passed in in UI, but not loading from .adm file.

This issue is not solved yet. Note that the ghost field /@value is added to the FHIR document. Also the real attribute doesn't get @ prefix it seems.

While we need a way to distinguish element and attribute for XML document, I don't think adding @ prefix to the field name is the best way. Instead for example, we can add an icon that indicates it's an attribute.
/myelement/@mychild and /myelement/mychild have to show differently in UI.
<myelement mychild="one">
  <mychild>the other</mychild>
</myelement>

So this is the correct mapping:
      "mapping" : [ {
        "jsonType" : "io.atlasmap.v2.Mapping",
        "inputField" : [ {
          "jsonType" : "io.atlasmap.xml.v2.XmlField",
          "docId" : "fhir-patient-246bb727-92e7-43e1-8da5-50abf8be1d17",
          "path" : "/tns:Patient/tns:id/@value",
          "fieldType" : "STRING",
          "name" : "value",
          "attribute" : false
        } ],
        "outputField" : [ {
          "jsonType" : "io.atlasmap.xml.v2.XmlField",
          "docId" : "fhir-patient-72a005cc-6a45-4573-89f7-bad2ecc9dd59",
          "path" : "/tns:Patient/tns:id/@value",
          "fieldType" : "STRING",
          "name" : "value",
          "attribute" : false
        } ],
        "id" : "mapping.654913"
      } ]

So specifically we want to continue to decorate the path with the @value - i.e. "path" : "/tns:Patient/tns:id/@value" but we do not want to display the @value  just tns:value - is that correct?

Let's see one by one

Now it might be better to file separate issues for the @ prefix. The most problematic issue here is the ghost field, non-existing field is added to the Document as it reloads, and eventually breaks the mapping.
The mapping definition in https://github.com/atlasmap/atlasmap/issues/1518#issuecomment-744631528 looks correct
Field.attribute should be true in theory. It might not be used yet though. Inspection already sets it true https://github.com/atlasmap/atlasmap/issues/1732
The path has to have @ prefix for the attribute
It was supposed to be shown as @tns:value or @value in the document tree, but now it is not. I think it's a bug since IIRC it used to be like that, and we need something to distinguish the attribute from the element with the same name (see https://github.com/atlasmap/atlasmap/issues/1518#issuecomment-744394433)
However, adding @ prefix directly to the display name doesn't look the best to indicate the attribute. We can improve it by showing an icon instead.
Even that, Field.name should not have @ prefix. This @ prefix issues are only about how to show in UI.


Documentation: Incorrect description on Chinese documentation

What happened?
On the official Chinese document, the scoop command gives an error:
scoop add bucket KusionStack https://github.com/KusionStack/scoop-bucket.git
What did you expect to happen?
It should be:
scoop bucket add KusionStack https://github.com/KusionStack/scoop-bucket.git
which is the same as the English document
How can we reproduce it (as minimally and precisely as possible)?
Fix this error.
Anything else we need to know?
No response
Kusion version

$ kusion version
# paste output here

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

fixed


Fix | 6.5 | KE | Health checks for old kube enforcers fails to render

Using the old Kube Enforcer liveness and readiness probes (which don't include /healthz) breaks the chart deployment due to this error:
Error: UPGRADE FAILED: cannot patch "aqua-kube-enforcer" with kind Deployment: Deployment.apps "aqua-kube-enforcer" is invalid: [spec.template.spec.containers[0].livenessProbe.tcpSocket: Forbidden: may not specify more than 1 handler type, spec.template.spec.containers[0].readinessProbe.tcpSocket: Forbidden: may not specify more than 1 handler type]

Indeed the rendered manifest looks like this:
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 30
  tcpSocket:
    port: 8080
readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 30
  tcpSocket:
    port: 8080

Apparently Helm keeps appending the httpGet prob, on top of the tcpSocket one, causing the issue.
In the fix I set an empty httpGet entry to prevent Helm from automatically rendering that bit.

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


Replace concourse.k8s.io API group with concourse.govsvc.uk

See https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190612-crd-group-protection.md
This will set up the new CRDs, change pipelines/teams in gsp.git to use it, change the pipeline-operator to deal with the new group, and adds commented out code to remove the old CRDs.
The next steps will be to make the same change in doc-checking, verify-proxy-node, and verify-metadata-controller. After this change and before those repositories have been updated, they will be unable to make changes to their pipeline.
When those are done then we can uncomment the code to remove the old CRD. Then we can remove the code that removed the old CRD.

@Krenair Conflicts to resolve on this m8.

Ah it's in the temporary cleanup area, just replacing that as it's no longer necessary

👍 hooray for getting rid of our k8s.io squatting.
How would you plan to roll this out? Is the idea that all tenants would have to add duplicate Pipeline resources in the old and new apigroups, and then we deploy this, and then tenants can delete the old Pipeline versions?  That sounds like a gnarly coordination problem and a nonzero amount of time where editing Pipelines in tenant repos is tricky because you have to remember to edit both yaml files.
An alternative rollout:

update this repo so that the pipeline operator supports BOTH the old AND the new apigroups
find each instance of a Pipeline object (both here, and in tenant repos) and update the apigroup to be the new one
remove support for the old apigroup

This would be a better experience for tenants, because they wouldn't have to dual-run two copies of each Pipeline. It might be more work for us though, but not that much more.
Thoughts?

We discussed IRL and we think the nicest way forward is to scale the pipeline-operator down to 0 while we change all of the existing Pipeline and Team resources.


Static object constructors do not execute on the NATIVE_POSIX_64 target

Describe the bug
All C++ global object constructors are not executed upon startup of a NATIVE_POSIX_64 executable. This breaks code that relies upon constructor side effects (such as registering unit tests with a test framework).
To Reproduce
Steps to reproduce the behavior:

Create a trivial C++ application with the following main.cc:

#include <string>
#include <iostream>

struct SideEffectConstructor {
    SideEffectConstructor(std::string s) {
        std::cerr << "Constructing " << s << std::endl;
    }
};

static auto object_a = SideEffectConstructor{"Object A"};
static auto object_b = SideEffectConstructor{"Object B"};
static auto object_c = SideEffectConstructor{"Object C"};
static auto object_d = SideEffectConstructor{"Object D"};

void main() {
    exit(0);
}

Build the application for the native_posix_64 target with following Kconfig:

CONFIG_CPLUSPLUS=y
CONFIG_LIB_CPLUSPLUS=y
CONFIG_STD_CPP20=y
CONFIG_ASSERT=y
CONFIG_SPEED_OPTIMIZATIONS=y

Execute the application.
Observe the following console output:

(.venv) bash-5.1$ ./build/zephyr/zephyr.elf
*** Booting Zephyr OS build v2.7.0-rc3-259-ga6dcf333a1b8  ***

Expected behavior
The following lines should be printed to the terminal exactly once:
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D

Impact
This bug results in a major discrepancy between the behavior of code running on the native_posix_64 board and the behavior of that same code running on physical board. This bug also interferes with the use of common unit test frameworks that rely on auto-registration of tests via global object constructors.
Environment (please complete the following information):

OS: (Linux)
Toolchain: Host GNU 11.2.1
Zephyr OS build v2.7.0-rc3-259-ga6dcf333a1b8

Additional context
The bug first appears at commit d10b46dc3be4492f5e7794c0a73c0e925d51c2ee.
#36858

@palchak-google FYI

Can you confirm that those four objects are actually in the resulting executable? What happens if you disable optimizations?
When I built my original example, I had all optimizations disabled. I think what may be happening is that the compiler can see that those four static objects are never used and thus they're being elided.

Can you confirm that those four objects are actually in the resulting executable? What happens if you disable optimizations?

CONFIG_CPLUSPLUS=y
CONFIG_LIB_CPLUSPLUS=y
CONFIG_STD_CPP20=y
CONFIG_ASSERT=y
CONFIG_NO_OPTIMIZATIONS=y

With configuration above all objects are present:
 .bss._ZL8object_a
                0x0000000000411d3d        0x1 app/libapp.a(main.cpp.obj)
 .bss._ZL8object_b
                0x0000000000411d3e        0x1 app/libapp.a(main.cpp.obj)
 .bss._ZL8object_c
                0x0000000000411d3f        0x1 app/libapp.a(main.cpp.obj)
 .bss._ZL8object_d
                0x0000000000411d40        0x1 app/libapp.a(main.cpp.obj)

Below you can find 2 archive with following files:
zephyr.elf  zephyr.lst  zephyr.map  zephyr.stat
With patch:
1.tar.gz
Without patch:
2.tar.gz

I am unable to reproduce this issue. I'm building with:
OS: Linux
Toolchain: gcc (Debian 10.3.0-11) 10.3.0
Zephyr: commit 86ad71827c8e56ec5d20da488fad3e514b155486 (HEAD, tag: v2.7.99, tag: v2.7.0-rc3)
I get the same output with native_posix and native_posix_64 targets:
$ ./zephyr/zephyr.elf
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D
*** Booting Zephyr OS build v2.7.99  ***

I do not have the ability at the moment to upgrade to GCC 11.2.1 to confirm whether the issue is related to the toolchain version (10.3.0 vs 11.2.1).
Project files used:
static_objects.zip

Well we have ourselves a real head scratcher here. I was able to install GCC v11.2.0 last week, and when building with that toolchain I also failed to reproduce the issue (for either native_posix or native_posix_64 target):
~/projects/zephyr-upstream/app/static_objs/BUILD.64 ❯❯❯ cmake .. -DBOARD=native_posix_64
Including boilerplate (Zephyr workspace): /usr/local/google/home/palchak/projects/zephyr-upstream/zephyr/cmake/app/boilerplate.cmake
-- Application: /usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs
-- Zephyr version: 2.7.0-rc3 (/usr/local/google/home/palchak/projects/zephyr-upstream/zephyr), build: v2.7.99
-- Found Python3: /usr/bin/python3.9 (found suitable exact version "3.9.7") found components: Interpreter
-- Found west (found suitable version "0.11.0", minimum required is "0.7.1")
-- Board: native_posix_64
-- Cache files will be written to: /usr/local/google/home/palchak/.cache/zephyr
-- Found dtc: /usr/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /usr/local/google/home/palchak/projects/zephyr-upstream/zephyr/boards/posix/native_posix/native_posix_64.dts
-- Generated zephyr.dts: /usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64/zephyr/dts.cmake
Parsing /usr/local/google/home/palchak/projects/zephyr-upstream/zephyr/Kconfig
Loaded configuration '/usr/local/google/home/palchak/projects/zephyr-upstream/zephyr/boards/posix/native_posix/native_posix_64_defconfig'
Merged configuration '/usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/prj.conf'
Configuration saved to '/usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64/zephyr/.config'
Kconfig header saved to '/usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Deprecation Warning at /usr/local/google/home/palchak/projects/zephyr-upstream/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

CMake Warning at /usr/local/google/home/palchak/projects/zephyr-upstream/zephyr/CMakeLists.txt:1643 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/google/home/palchak/projects/zephyr-upstream/app/static_objs/BUILD.64
~/projects/zephyr-upstream/app/static_objs/BUILD.64 ❯❯❯ ninja
[1/99] Preparing syscall dependency handling

[94/99] Linking CXX executable zephyr/zephyr_prebuilt.elf

[99/99] Linking CXX executable zephyr/zephyr.elf
~/projects/zephyr-upstream/app/static_objs/BUILD.64 ❯❯❯ ./zephyr/zephyr.elf
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D
*** Booting Zephyr OS build v2.7.99  ***

As a sanity check, what happens if you build the executable without Zephyr at all? That is, change the signature of main to int main() and then build a simple executable:
gcc -o test.elf ../main.cc -lstdc++ -lgcc

I get the following output (as expected):
~/projects/zephyr-upstream/app/static_objs/BUILD.noz ❯❯❯ ./test.elf
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D

Also, since you happen to be using GCC-11, take note of issue #40023.

Hello,
I observed this problem after upgrade of Ubuntu from 20.04 to 22.04. In tests I used static_obs example from this thread. Only change is that C++ is set to 17 instead of 20.
Ubuntu 20.04 GCC 9.4 -> works perfect
user@ubuntu20 /b/g/z/static_objs (develop)> west build -b native_posix -t run
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /build/griffin_root/zephyr_base/static_objs
-- Found Python3: /usr/bin/python3.8 (found suitable exact version "3.8.10") found components: Interpreter
-- Cache files will be written to: /home/user/.cache/zephyr
-- Zephyr version: 3.0.99 (/build/griffin_root/zephyr_base/zephyr)
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: native_posix
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /build/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix.dts
-- Generated zephyr.dts: /build/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /build/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /build/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /build/griffin_root/zephyr_base/static_objs/build/zephyr/dts.cmake
Parsing /build/griffin_root/zephyr_base/zephyr/Kconfig
Loaded configuration '/build/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix_defconfig'
Merged configuration '/build/griffin_root/zephyr_base/static_objs/prj.conf'
Configuration saved to '/build/griffin_root/zephyr_base/static_objs/build/zephyr/.config'
Kconfig header saved to '/build/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Warning at /build/griffin_root/zephyr_base/zephyr/CMakeLists.txt:1803 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /build/griffin_root/zephyr_base/static_objs/build
-- west build: running target run
[1/102] Preparing syscall dependency handling

[2/102] Generating include/generated/version.h
-- Zephyr version: 3.0.99 (/build/griffin_root/zephyr_base/zephyr), build: zephyr-v3.0.0-2756-gc5dc184b7432
[97/102] Linking CXX executable zephyr/zephyr_pre0.elf

[101/102] Linking CXX executable zephyr/zephyr.elf

[101/102] cd /build/griffin_root/zephyr_base/static_objs/build && /build/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.exe
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D
*** Booting Zephyr OS build zephyr-v3.0.0-2756-gc5dc184b7432  ***

Ubuntu 22.04 GCC 11.2 -> ctors are not executed
user@ubuntu22 /m/w/c/g/z/static_objs (develop)> west build -b native_posix -t run
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /media/wsl/code/griffin_root/zephyr_base/static_objs
-- Found Python3: /usr/bin/python3.10 (found suitable exact version "3.10.4") found components: Interpreter
-- Cache files will be written to: /home/user/.cache/zephyr
-- Zephyr version: 3.0.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: native_posix
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix.dts
-- Generated zephyr.dts: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/dts.cmake
Parsing /media/wsl/code/griffin_root/zephyr_base/zephyr/Kconfig
Loaded configuration '/media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix_defconfig'
Merged configuration '/media/wsl/code/griffin_root/zephyr_base/static_objs/prj.conf'
Configuration saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/.config'
Kconfig header saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Warning at /media/wsl/code/griffin_root/zephyr_base/zephyr/CMakeLists.txt:1803 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /media/wsl/code/griffin_root/zephyr_base/static_objs/build
-- west build: running target run
[1/102] Preparing syscall dependency handling

[2/102] Generating include/generated/version.h
-- Zephyr version: 3.0.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr), build: zephyr-v3.0.0-2756-gc5dc184b7432
[97/102] Linking CXX executable zephyr/zephyr_pre0.elf

[101/102] Linking CXX executable zephyr/zephyr.elf

[101/102] cd /media/wsl/code/griffin_root/zephyr_base/static_objs/build && /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.exe
*** Booting Zephyr OS build zephyr-v3.0.0-2756-gc5dc184b7432  ***

When I compiled and run this as normal application constructors works properly.
user@ubuntu22 /m/w/c/g/z/static_objs (develop)> gcc -o test.elf main.cc -lstdc++
user@ubuntu22 /m/w/c/g/z/static_objs (develop)> ./test.elf
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D

The differing results with different toolchains points indicates that this likely has something to do with a change in libstdc++. For reference, I used the following toolchain and library to build for native_posix, native_posix_64, and native Linux (non-Zephyr) targets:

gcc (Debian 11.2.0-16) 11.2.0
libstdc++-11-dev:amd64 11.2.0-16
libstdc++-11-dev:i386  11.2.0-16

These version are all installed via official Debian packages.
Re-building with the latest ToT for Zephyr again fails to reproduce for me:
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D
*** Booting Zephyr OS build zephyr-v3.0.0-3121-gd490358e283f  ***

I made some more checks in Ubuntu 22.04, looks like constructors works properly only in GCC 9.
wsl@T15 /m/w/c/g/z/static_objs (develop)> sudo apt install gcc-9 g++-9 g++-9-multilib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
g++-9 is already the newest version (9.4.0-5ubuntu1).
g++-9-multilib is already the newest version (9.4.0-5ubuntu1).
gcc-9 is already the newest version (9.4.0-5ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
wsl@T15 /m/w/c/g/z/static_objs (develop)> sudo update-alternatives --set gcc /usr/bin/gcc-9
update-alternatives: using /usr/bin/gcc-9 to provide /usr/bin/gcc (gcc) in manual mode
wsl@T15 /m/w/c/g/z/static_objs (develop)> sudo update-alternatives --set g++ /usr/bin/g++-9
update-alternatives: using /usr/bin/g++-9 to provide /usr/bin/g++ (g++) in manual mode
wsl@T15 /m/w/c/g/z/static_objs (develop)> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-bVKGhJ/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-5ubuntu1)
wsl@T15 /m/w/c/g/z/static_objs (develop)> rm build -fr
wsl@T15 /m/w/c/g/z/static_objs (develop)> west build -b native_posix -t run
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /media/wsl/code/griffin_root/zephyr_base/static_objs
-- Found Python3: /usr/bin/python3.10 (found suitable exact version "3.10.4") found components: Interpreter
-- Cache files will be written to: /home/wsl/.cache/zephyr
-- Zephyr version: 3.0.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: native_posix
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix.dts
-- Generated zephyr.dts: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/dts.cmake
Parsing /media/wsl/code/griffin_root/zephyr_base/zephyr/Kconfig
Loaded configuration '/media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix_defconfig'
Merged configuration '/media/wsl/code/griffin_root/zephyr_base/static_objs/prj.conf'
Configuration saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/.config'
Kconfig header saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Warning at /media/wsl/code/griffin_root/zephyr_base/zephyr/CMakeLists.txt:1803 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /media/wsl/code/griffin_root/zephyr_base/static_objs/build
-- west build: running target run
[1/102] Preparing syscall dependency handling

[3/102] Generating include/generated/version.h
-- Zephyr version: 3.0.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr), build: zephyr-v3.0.0-3163-g7ad2e604bb31
[97/102] Linking CXX executable zephyr/zephyr_pre0.elf

[101/102] Linking CXX executable zephyr/zephyr.elf

[101/102] cd /media/wsl/code/griffin_root/zephyr_base/static_objs/build && /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.exe
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D
*** Booting Zephyr OS build zephyr-v3.0.0-3163-g7ad2e604bb31  ***

For any other GCC (10, 11, 12) from ubuntu 22.04 constructors are not executed. In this example I used 10, but 11 and 12 works exactly the same.
wsl@T15 /m/w/c/g/z/static_objs (develop)> sudo apt install gcc-10 g++-10 g++-10-multilib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
g++-10 is already the newest version (10.3.0-15ubuntu1).
g++-10-multilib is already the newest version (10.3.0-15ubuntu1).
gcc-10 is already the newest version (10.3.0-15ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
wsl@T15 /m/w/c/g/z/static_objs (develop)> sudo update-alternatives --set gcc /usr/bin/gcc-10
update-alternatives: using /usr/bin/gcc-10 to provide /usr/bin/gcc (gcc) in manual mode
wsl@T15 /m/w/c/g/z/static_objs (develop)> sudo update-alternatives --set g++ /usr/bin/g++-10
update-alternatives: using /usr/bin/g++-10 to provide /usr/bin/g++ (g++) in manual mode
wsl@T15 /m/w/c/g/z/static_objs (develop)> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-15ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-15ubuntu1)
wsl@T15 /m/w/c/g/z/static_objs (develop)> rm build -fr
wsl@T15 /m/w/c/g/z/static_objs (develop)> west build -b native_posix -t run
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /media/wsl/code/griffin_root/zephyr_base/static_objs
-- Found Python3: /usr/bin/python3.10 (found suitable exact version "3.10.4") found components: Interpreter
-- Cache files will be written to: /home/wsl/.cache/zephyr
-- Zephyr version: 3.0.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: native_posix
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix.dts
-- Generated zephyr.dts: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/dts.cmake
Parsing /media/wsl/code/griffin_root/zephyr_base/zephyr/Kconfig
Loaded configuration '/media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix_defconfig'
Merged configuration '/media/wsl/code/griffin_root/zephyr_base/static_objs/prj.conf'
Configuration saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/.config'
Kconfig header saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Warning at /media/wsl/code/griffin_root/zephyr_base/zephyr/CMakeLists.txt:1803 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /media/wsl/code/griffin_root/zephyr_base/static_objs/build
-- west build: running target run
[1/102] Preparing syscall dependency handling

[2/102] Generating include/generated/version.h
-- Zephyr version: 3.0.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr), build: zephyr-v3.0.0-3163-g7ad2e604bb31
[97/102] Linking CXX executable zephyr/zephyr_pre0.elf

[101/102] Linking CXX executable zephyr/zephyr.elf

[101/102] cd /media/wsl/code/griffin_root/zephyr_base/static_objs/build && /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.exe
*** Booting Zephyr OS build zephyr-v3.0.0-3163-g7ad2e604bb31  ***

Exactly the same behavior I observed for native_posix and native_posix_64
Nevertheless current behavior, when constructors are not executed directly after start of the application, and after reverting of this commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee is matching to this Enhancement https://github.com/zephyrproject-rtos/zephyr/issues/40444

Commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee addresses a defect in Zephyr reported in https://github.com/zephyrproject-rtos/zephyr/issues/39347. However, further investigation has revealed that https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee does not correctly resolve the root cause of the issue. Additionally,  https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee is currently masking a second, latent defect in Zephyr.
Background
To understand the root cause of the issue, it's necessary to have familiarity with the start-up sequence for processes on Linux. This article provides a great explanation of each of the steps in detail.
Root cause of https://github.com/zephyrproject-rtos/zephyr/issues/36858
The root cause of https://github.com/zephyrproject-rtos/zephyr/issues/36858 lies in the interaction between the link script used by Zephyr for native_posix targets and the start-up sequence for glibc. To understand what's happening it helps to look at the map file for a native_posix binary. Here is the map for a binary built on my system using the example code from https://github.com/zephyrproject-rtos/zephyr/issues/36858.
.init_array     0x000000000040bd90        0x0
                [!provide]                        PROVIDE (__init_array_start = .)
 *(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*))
 *(SORT_BY_ALIGNMENT(.init_array) SORT_BY_ALIGNMENT(EXCLUDE_FILE(*crtend?.o *crtend.o *crtbegin?.o *crtbegin.o) .ctors))
                [!provide]                        PROVIDE (__init_array_end = .)

.ctors
 *crtbegin.o(SORT_BY_ALIGNMENT(.ctors))
 *crtbegin?.o(SORT_BY_ALIGNMENT(.ctors))
 *(SORT_BY_ALIGNMENT(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors))
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(.ctors.*)))
 *(SORT_BY_ALIGNMENT(.ctors))

ctors           0x00000000080532c8       0x14
                0x00000000080532c8                . = ALIGN (0x4)
                0x00000000080532c8                __CTOR_LIST__ = .
                0x00000000080532c8        0x4 LONG 0x3 (((__CTOR_END__ - __CTOR_LIST__) / 0x4) - 0x2)
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(.ctors*)))
 .ctors         0x00000000080532cc        0x4 /usr/lib/gcc/x86_64-linux-gnu/11/32/crtbegin.o
 .ctors         0x00000000080532d0        0x4 app/libapp.a(main.cc.obj)
 .ctors         0x00000000080532d4        0x4 /usr/lib/gcc/x86_64-linux-gnu/11/32/crtend.o
                0x00000000080532d8        0x4 LONG 0x0
                0x00000000080532dc                __CTOR_END__ = .

init_array      0x00000000080532dc        0x0
                0x00000000080532dc                . = ALIGN (0x4)
                0x00000000080532dc                __init_array_start = .
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(.init_array*)))
                0x00000000080532dc                __init_array_end = .

Note here that the ctors section ends up containing five quad words:
$ > readelf -x ctors zephyr.elf

Hex dump of section 'ctors':
  0x080532c8 03000000 ffffffff 90960408 00000000 ................
  0x080532d8 00000000                            ....

The first word (0x03) and the last word (0x0) are inserted by Zephyr's link script (the QUAD directives in the map file). The middle three words come from crtbegin.o, main.cc.obj, and crtend.o. The word from crtbegin.o is a value of -1, the word from crtend.o is 0x0, and the word from main.cc.obj is 0x08049690 which is the address of the initialization function that invokes the constructors for our static objects:
$> objdump -t zephyr.elf | grep "08049690" -
08049690 l     F .text	000000c4              _GLOBAL__sub_I_zephyr_app_main

It's also important to note that there are two symbols in the binary, both named __CTOR_LIST__, that point into the ctors section:
$> objdump -t zephyr.elf | grep "CTOR_LIST" -
080532cc l     O ctors	00000000              __CTOR_LIST__
080532c8 g       ctors	00000000              __CTOR_LIST__

The first symbol refers to a local object (the 'l' and 'O' flags) at address 0x080532cc, which is the address of the value -1 that was contributed by crtbegin.o. The second symbol is a global symbol referring to the 0x03 inserted by Zephyr's link script.
The final piece of the puzzle lies in the _init function for this native_posix executable:
$> objdump -dj .init zephyr.elf

zephyr.elf:     file format elf64-x86-64

Disassembly of section .init:

0000000000402000 <_init>:
  402000:	48 83 ec 08          	sub    $0x8,%rsp
  402004:	48 8b 05 dd 9f 00 00 	mov    0x9fdd(%rip),%rax        # 40bfe8 <__gmon_start__@Base>
  40200b:	48 85 c0             	test   %rax,%rax
  40200e:	74 02                	je     402012 <_init+0x12>
  402010:	ff d0                	call   *%rax
  402012:	e8 49 04 00 00       	call   402460 <frame_dummy>
  402017:	e8 84 63 00 00       	call   4083a0 <__do_global_ctors_aux>
  40201c:	48 83 c4 08          	add    $0x8,%rsp
  402020:	c3                   	ret

The _init function makes a direct call to the __do_global_ctors_aux function, consistent with the normal start-up sequence for a Linux process. And __do_global_ctors_aux in turn iterates through the list denoted by the __CTOR_LIST__ symbol and calls each function pointer contained in the list. All of this happens before control passes to Zephyr's init code. When Zephyr's init code runs it repeats the process of iterating through the __CTOR_LIST__ (Zephyr provides its own implementation of __do_global_ctors_aux), resulting in duplicate calls to all static object constructors. This explains the behavior reported in https://github.com/zephyrproject-rtos/zephyr/issues/36858. This also explains why commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee appeared to fix the issue: it eliminated a call to Zephyr's  __do_global_ctors_aux function and thus prevented duplicate constructor calls.
Root cause of https://github.com/zephyrproject-rtos/zephyr/issues/39347
Commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee fixed the Zephyr start-up process on some systems but broke the start-up process on others. An understanding as to why is provided again by the map file. This excerpt is taken from the map file for the native_posix binary provided by aleksei-timofeyev in an earlier comment:
ctors           0x0000000000411608       0x10
                0x0000000000411608                . = ALIGN (0x8)
                0x0000000000411608                __CTOR_LIST__ = .
                0x0000000000411608        0x8 QUAD 0x0 (((__CTOR_END__ - __CTOR_LIST__) / 0x8) - 0x2)
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(.ctors*)))
                0x0000000000411610        0x8 QUAD 0x0
                0x0000000000411618                __CTOR_END__ = .

init_array      0x0000000000411618       0x10
                0x0000000000411618                . = ALIGN (0x4)
                0x0000000000411618                __init_array_start = .
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(.init_array*)))
 .init_array    0x0000000000411618        0x8 /usr/lib/gcc/x86_64-redhat-linux/11/crtbegin.o
 .init_array    0x0000000000411620        0x8 app/libapp.a(main.cpp.obj)
                0x0000000000411628                __init_array_end = .

On Aleksei's system, the ctors section in the final binary is empty, while the init_array section contains the pointer to the initialization function for the static objects. Also note that Aleksei built 64-bit executables, so the words are 8 bytes long.
$> readelf -x ctors zephyr.elf

Hex dump of section 'ctors':
  0x00411608 00000000 00000000 00000000 00000000 ................

$> readelf -x init_array zephyr.elf

Hex dump of section 'init_array':
  0x00411618 60244000 00000000 f2354000 00000000 `$<EMAIL_ADDRESS>
$> objdump -t zephyr.elf| grep "402460" -
0000000000402460 l     F .text<PHONE_NUMBER>000000              frame_dummy

$> objdump -t zephyr.elf| grep "4035f2" -
00000000004035f2 l     F .text<PHONE_NUMBER>000015              _GLOBAL__sub_I_main.cpp

The other critical detail is that the _init function on Aleksei's system is different:
$> objdump -dj .init zephyr.elf

zephyr.elf:     file format elf64-x86-64

Disassembly of section .init:

0000000000402000 <_init>:
  402000:	f3 0f 1e fa          	endbr64
  402004:	48 83 ec 08          	sub    $0x8,%rsp
  402008:	48 8b 05 e9 ef 00 00 	mov    0xefe9(%rip),%rax        # 410ff8 <__gmon_start__@Base>
  40200f:	48 85 c0             	test   %rax,%rax
  402012:	74 02                	je     402016 <_init+0x16>
  402014:	ff d0                	call   *%rax
  402016:	48 83 c4 08          	add    $0x8,%rsp
  40201a:	c3                   	ret

On Aleksei's sytem, the _init function does not directly call __do_global_constructors_aux. This means that on Aleksei's sytem, no global constructors run before control is passed to Zephyr's init code. And since commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee disables Zephyr's execution of all initialization functions, on Aleksei's sytem the static object constructors never run.
Different behavior on different systems
The difference in process start-up behavior between my system and Aleksei's system can be attributed to significant changes that were introduced to glibc starting with version 2.34. Many of the changes are explained and motivated in this StackOverflow answer. The one change that has a critical impact on this issue is the elimination of the direct call to __do_global_constructors_aux within the _init function.
Without commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee, on systems with glibc < 2.34 the call to __do_global_constructors_aux in _init causes global constructors to run twice. On systems with glibc >= 2.34, global constructors run exactly once during Zephyr's init.
With commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee, on systems with glibc < 2.34 global constructors run exactly once prior to Zephyr's init, and on systems with glibc >= 2.34 global constructors never run at all.
Glibc v2.34 was officially released in August of 2021, though some distributions adopted it earlier. It seems all but certain that Ubuntu 20.04 included a version of glibc prior older than 2.34 while Ubuntu 22.04 uses a version of glibc >= 2.34. This explains wojciechslenska's results.
Fixing both https://github.com/zephyrproject-rtos/zephyr/issues/39347 and https://github.com/zephyrproject-rtos/zephyr/issues/36858
The solution that works for both systems using glibc < 2.34 and systems using glibc >= 2.34 is to revert commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee and instead modify the Zephyr link script (for native_posix platforms) to split up the the contents of the .ctors section into two different lists.
The first list contains only the symbols provided by the crtbegin.o and crtend.o objects. Including only the symbols from crtbegin.o and crtend.o ensures that this list always remains empty. The address of this empty list is assigned to the __CTOR_LIST__ symbol. For systems with glibc < 2.34 the call to __do_global_ctors_aux in _init processes this empty list, and because it's empty no initialization functions actually run. For systems with glibc >= 2.34 this empty list is simply never used.
The second list contains all of the remaining symbols from the .ctors sections, that is, all .ctors* symbols except for those provided by crtbegin.o and crtend.o objects. This address of this second list is assigned to a newly invented symbol called __ZEPYHYR_CTOR_LIST__. Only Zephyr is aware of this second list, and thus only Zephyr's init code calls the functions included in this list. For systems with glibc < 2.34, this ensures that initialization functions in .ctors sections run exactly once during Zephyr's start-up. For systems with glibc >= 2.34, initialization functions are placed in .init_array sections instead of .ctors sections, meaning this second list is also always empty. As a result on these systems the call to Zephyr's __do_global_ctors_aux has no effect.
Finally, one important feature of this solution that is not present in commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee is that with this solution static object constructors run as part of Zephyr's start-up routine (instead of before Zephyr). This means that static object constructors run after kernel and driver initialization, exactly as occurs on non-posix platforms. This sequencing is important, as constructors may interact with the kernel or with drivers. It is certainly a defect for any such interactions to occur before the kernel and drivers have been initialized, as is possible today with commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee.
I will work on producing a patch that implements this solution in the coming weeks. If someone else wants to take a shot at implementation in the mean time, please do.
Coda
At the beginning I mentioned that commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee is currently masking a latent defect in Zephyr.  Recall the relevant map file section for and contents of the ctors section for the native_posix executable built on my system:
ctors           0x00000000080532c8       0x14
                0x00000000080532c8                . = ALIGN (0x4)
                0x00000000080532c8                __CTOR_LIST__ = .
                0x00000000080532c8        0x4 LONG 0x3 (((__CTOR_END__ - __CTOR_LIST__) / 0x4) - 0x2)
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(.ctors*)))
 .ctors         0x00000000080532cc        0x4 /usr/lib/gcc/x86_64-linux-gnu/11/32/crtbegin.o
 .ctors         0x00000000080532d0        0x4 app/libapp.a(main.cc.obj)
 .ctors         0x00000000080532d4        0x4 /usr/lib/gcc/x86_64-linux-gnu/11/32/crtend.o
                0x00000000080532d8        0x4 LONG 0x0
                0x00000000080532dc                __CTOR_END__ = .

$ > readelf -x ctors zephyr.elf

Hex dump of section 'ctors':
  0x080532c8 03000000 ffffffff 90960408 00000000 ................
  0x080532d8 00000000

The __do_global_constructors_aux function expects the __CTOR_LIST__ symbol to point to a list of pointers to initialization functions. Furthermore, that list is expected to have a specific binary format, as documented here. To summarize the format, the first entry of the list is always ignored, and it may contain either 0, -1, or a count of the number of function pointers following it. The last entry of the list must be the value zero (aka a null function pointer).
Looking closely at the initialization function list in the final binary we see that it contains five entries:
{
    [0] = 0x03
    [1] = 0xFFFFFFFF
    [2] = 0x08049690
    [3] = 0x0
    [4] = 0x0
}

The first entry indicates that the list contains three valid pointers, and the last entry is the trailing zero. However, entry[1], which is supposedly a function pointer, has the value -1. Similarly, entry[3] is a nullptr. Only the entry[2] is a valid function pointer. What Zephyr's link script has done is take a valid list (entries 1-3) and wrapped with with a leading size (0x03) and a trailing zero, resulting in a final list that contains invalid pointers. And indeed, if commit https://github.com/zephyrproject-rtos/zephyr/commit/d10b46dc3be4492f5e7794c0a73c0e925d51c2ee is reverted, Zephyr's version of __do_global_ctors_aux produces a segfault when it tries to deference the entry[1]:
$> ./zephyr.elf
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D
*** Booting Zephyr OS build zephyr-v3.0.0-3121-gd490358e283f  ***
[1]    41238 segmentation fault  ./zephyr.elf

Notice in this output that even though Zephyr generates a __CTOR_LIST__ with invalid entries, the static object constructors are correctly executed before Zephyr's init code runs. The explanation for why the call to __do_global_ctors_aux in _init succeeds while Zephyr's version of __do_global_ctors_aux fails lies in the symbol table:
$> objdump -t zephyr.elf | grep "CTOR_LIST" -
080532cc l     O ctors	00000000              __CTOR_LIST__
080532c8 g       ctors	00000000              __CTOR_LIST__

The executable contains two symbols named __CTOR_LIST__ that point to different addresses. The __do_global_ctors_aux function called from _init references the first symbol, the one that describes a local object. That symbol represents address 0x080532cc, which corresponds to the entry[1]. When entry[1] is treated as the start of the list (instead of entry[0]) the code does not encounter any invalid entries prior to the (first) trailing null.
In contrast, Zephyr's version of __do_global_ctors_aux references the second symbol, the global version. This symbol points to entry[0]. Thus when Zephyr's __do_global_ctors_aux attempts to dereference entry[1] as a function pointer a fault occurs.
Because the proposed fix for https://github.com/zephyrproject-rtos/zephyr/issues/39347 and https://github.com/zephyrproject-rtos/zephyr/issues/36858 will also eliminate this latent defect, it doesn't seem necessary to file a separate bug report for it. However, if others disagree, then please feel free to copy this coda into a stand-alone report.

@aleksei-timofeyev
@wojciechslenska
I have submitted a fix for this issue. It works as best as I have been able to test. Will you please confirm the fix works properly on your system(s)?
https://github.com/zephyrproject-rtos/zephyr/pull/46357

@palchak-google
Hello,
I can confirm that now constructors are working properly on Ubuntu 22.04 on GCC 10.3.0
wsl@T15 /m/w/c/g/z/static_objs (wsl/database_test)> west build -b native_posix -t run
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /media/wsl/code/griffin_root/zephyr_base/static_objs
-- Found Python3: /usr/bin/python3.10 (found suitable exact version "3.10.4") found components: Interpreter
-- Cache files will be written to: /home/wsl/.cache/zephyr
-- Zephyr version: 3.1.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: native_posix
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix.dts
-- Generated zephyr.dts: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/dts.cmake
Parsing /media/wsl/code/griffin_root/zephyr_base/zephyr/Kconfig
Loaded configuration '/media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix_defconfig'
Merged configuration '/media/wsl/code/griffin_root/zephyr_base/static_objs/prj.conf'
Configuration saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/.config'
Kconfig header saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Warning at /media/wsl/code/griffin_root/zephyr_base/zephyr/CMakeLists.txt:1809 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /media/wsl/code/griffin_root/zephyr_base/static_objs/build
-- west build: running target run
[1/102] Preparing syscall dependency handling

[2/102] Generating include/generated/version.h
-- Zephyr version: 3.1.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr), build: zephyr-v3.1.0-346-gb9e833366f13
[97/102] Linking CXX executable zephyr/zephyr_pre0.elf

[101/102] Linking CXX executable zephyr/zephyr.elf

[101/102] cd /media/wsl/code/griffin_root/zephyr_base/static_objs/build && /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.exe
*** Booting Zephyr OS build zephyr-v3.1.0-346-gb9e833366f13  ***
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D

and GCC 12.0.1
wsl@T15 /m/w/c/g/z/static_objs (wsl/database_test)> west build -b native_posix -t run
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /media/wsl/code/griffin_root/zephyr_base/static_objs
-- Found Python3: /usr/bin/python3.10 (found suitable exact version "3.10.4") found components: Interpreter
-- Cache files will be written to: /home/wsl/.cache/zephyr
-- Zephyr version: 3.1.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr)
-- Found west (found suitable version "0.13.1", minimum required is "0.7.1")
-- Board: native_posix
-- Found toolchain: host (gcc/ld)
-- Found BOARD.dts: /media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix.dts
-- Generated zephyr.dts: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/dts.cmake
Parsing /media/wsl/code/griffin_root/zephyr_base/zephyr/Kconfig
Loaded configuration '/media/wsl/code/griffin_root/zephyr_base/zephyr/boards/posix/native_posix/native_posix_defconfig'
Merged configuration '/media/wsl/code/griffin_root/zephyr_base/static_objs/prj.conf'
Configuration saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/.config'
Kconfig header saved to '/media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 12.0.1
-- The CXX compiler identification is GNU 12.0.1
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
CMake Warning at /media/wsl/code/griffin_root/zephyr_base/zephyr/CMakeLists.txt:1809 (message):
  __ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: /media/wsl/code/griffin_root/zephyr_base/static_objs/build
-- west build: running target run
[1/102] Preparing syscall dependency handling

[2/102] Generating include/generated/version.h
-- Zephyr version: 3.1.99 (/media/wsl/code/griffin_root/zephyr_base/zephyr), build: zephyr-v3.1.0-346-gb9e833366f13
[97/102] Linking CXX executable zephyr/zephyr_pre0.elf

[101/102] Linking CXX executable zephyr/zephyr.elf

[101/102] cd /media/wsl/code/griffin_root/zephyr_base/static_objs/build && /media/wsl/code/griffin_root/zephyr_base/static_objs/build/zephyr/zephyr.exe
*** Booting Zephyr OS build zephyr-v3.1.0-346-gb9e833366f13  ***
Constructing Object A
Constructing Object B
Constructing Object C
Constructing Object D

I see the same behavior on native_posix and native_posix_64
Many thanks for your contribution


[skip ci] Remove FAQ

This is sufficiently out of date and has a sufficiently narrow scope that I believe it does more harm than good
cc @jakirkham

As per our discussion the other day, still disagree with this until the content has actually migrated elsewhere in the docs. Once that happens this is a different story. TBH I don't think that migration should be hard. At a bare minimum the text could be lifted and moved to other sections.
In particular, the rule of thumb about chunk sizes comes up every time we have a new user to Dask Array and it isn't anywhere else in the docs. FTR this was the same objection I had last time.

Chunks: http://dask.pydata.org/en/latest/array-creation.html#chunks
Debug: http://dask.pydata.org/en/latest/understanding-performance.html
How do I spill to disk: Current FAQ recommends chest, which I think is bad advice at this point
Serialize functions: I think that this is overly technical for a FAQ.  It is, in fact, not a FAQ

There is also a question on Stack Overflow for chunks: https://stackoverflow.com/questions/34895846/correct-choice-of-chunks-specification-for-dask-array

How would you feel about redirecting the FAQ to stack overflow: https://stackoverflow.com/questions/tagged/dask?sort=frequent&pageSize=30 ?
This has arguably a much better collection of questions and answers

Would add the 4 item from that list in the FAQ to 1-3 in the chunks section.
ref: http://dask.pydata.org/en/latest/array-creation.html#chunks

Done
On Thu, May 3, 2018 at 9:56 AM, jakirkham<EMAIL_ADDRESS>wrote:

Would add the 4 item from that list in the FAQ to 1-3 in the chunks
section.
ref: http://dask.pydata.org/en/latest/array-creation.html#chunks
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/3465#issuecomment-386304291, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AASszI28nGiYF1a6sP2HAn_CdtJuGDr2ks5tuwydgaJpZM4TxBNU
.

We should reference dask.get by name in this section.

I recommend that we handle this in #3442

Good point. Wasn't thinking about that. Noted in this comment.

How do I spill to disk: Current FAQ recommends chest, which I think is bad advice at this point

Unfortunately agree. We don't have a good solution for that now.

Ok, think this works now. Sorry for the resistance.

This has been a useful conversation.  It seems like we moved over parts of the FAQ that you found valuable.  This also forced me to think about linking to Stack Overflow questions, which might be something to pursue in the future.
Thanks for the engagement.  I'll be happy to merge this!


Fix: videos in LLaVa-OV

Currently running the demo notebook for LLaVA OneVision for video modality doesn't apply pooling for all video patches/frames, because the modality list holds values for each prompt, while videos can contain several frames. This PR replicates the modality list by copying it for all video frames in the demo notebook
I tried to see if we can expand the modalities inside modeling code, but seems like it's hard to infer which visual in the input is image or video, so I decided to delegate expansion to users.

Hi @zucchini-nlp , may I ask what is your token size when you printed out in your notebook? In #144 , I printed out the tokens size and it seems that all frames have been pooled.

@zucchini-nlp , I think there will be one newline token at the end of all video frames instead of one image_newline token at the end of each frame. The place I print in #144 is after the pooling but before the concat of image_newline. May I ask how did you process your video frames? If you provide the model frame by frame then it is likely you get 197 tokens per frame and multiple video modalities need to be provided. But I think if you provide the video in one batch then should be 196 tokens per frame and 1 image token at the end of all tokens

@kcz358 Right, I was providing it frame by frame using the demo notebook, but if I change it to one tensor per video as follows, it works as you described. Thanks!
from llava.model.builder import load_pretrained_model
from llava.mm_utils import get_model_name_from_path, process_images, tokenizer_image_token
from llava.constants import IMAGE_TOKEN_INDEX, DEFAULT_IMAGE_TOKEN, DEFAULT_IM_START_TOKEN, DEFAULT_IM_END_TOKEN, IGNORE_INDEX
from llava.conversation import conv_templates, SeparatorStyle

from PIL import Image
import cv2
import numpy as np
import requests
import copy
import torch

import sys
import warnings

warnings.filterwarnings("ignore")
pretrained = "lmms-lab/llava-onevision-qwen2-0.5b-ov"
model_name = "llava_qwen"
device = "cuda"
device_map = "auto"
tokenizer, model, image_processor, max_length = load_pretrained_model(pretrained, None, model_name, device_map=device_map)  # Add any other thing you want to pass in llava_model_args

model.eval()

# Function to extract frames from video
def extract_frames(video_path, num_frames=8):
    cap = cv2.VideoCapture(video_path)
    frames = []
    total_frames = int(cap.get(cv2.CAP_PROP_FRAME_COUNT))
    indices = np.linspace(0, total_frames - 1, num_frames, dtype=int)

    for i in indices:
        cap.set(cv2.CAP_PROP_POS_FRAMES, i)
        ret, frame = cap.read()
        if ret:
            frame = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)
            frames.append(Image.fromarray(frame))

    cap.release()
    return frames

# Load and process video
video_path = "/raid/raushan/karate.mp4"
video_frames = extract_frames(video_path)
image_tensor = image_processor.preprocess(video_frames, return_tensors="pt")["pixel_values"].half().cuda()

conv_template = "qwen_1_5"  # Make sure you use correct chat template for different models
question = f"{DEFAULT_IMAGE_TOKEN}\nDescribe what's happening in this video."
conv = copy.deepcopy(conv_templates[conv_template])
conv.append_message(conv.roles[0], question)
conv.append_message(conv.roles[1], None)
prompt_question = conv.get_prompt()

input_ids = tokenizer_image_token(prompt_question, tokenizer, IMAGE_TOKEN_INDEX, return_tensors="pt").unsqueeze(0).to(device)
print(image_tensor.shape)

cont = model.generate(
    input_ids,
    images=[image_tensor],
    do_sample=False,
    temperature=0,
    top_p=1.0,
    max_new_tokens=4096,
    modalities=["video"]
)
text_outputs = tokenizer.batch_decode(cont, skip_special_tokens=True)
print(text_outputs)


Changes for the week of Aug 26

make epoch global to the Resource
check versionid on update when updating the Resource's default Version props
add location to Resource model attributes (resource, version, both)
removed exportrequired
added back in $import (as $include)
added ?resource to exclude the default Version attributes on a Resource
added /export - same as /?export - for static file server cases

Approved on the 8/29 call


refactor(pointcloud_preprocessor): rework parameters

Description
Implement the ROS Node configuration layout for the sensing/pointcloud_preprocessor package.
Test performed

Build

colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release --packages-up-to autoware_vehicle_info_utils
colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPE=Release --packages-up-to pointcloud_preprocessor

Launch

ros2 launch pointcloud_preprocessor approximate_downsample_filter.launch.xml
ros2 launch pointcloud_preprocessor blockage_diag.launch.xml
ros2 launch pointcloud_preprocessor distortion_corrector.launch.xml
ros2 launch  pointcloud_preprocessor dual_return_outlier_filter.launch.xml
ros2 launch pointcloud_preprocessor lanelet2_map_filter.launch.xml
ros2 launch pointcloud_preprocessor pickup_based_voxel_grid_downsample_filter.launch.xml
ros2 launch pointcloud_preprocessor pointcloud_accumulator.launch.xml
ros2 launch pointcloud_preprocessor polygon_remover.launch.py
ros2 launch pointcloud_preprocessor preprocessor.launch.xml
ros2 launch pointcloud_preprocessor radius_search_2d_outlier_filter.launch.xml
ros2 launch pointcloud_preprocessor random_downsample_filter.launch.xml
ros2 launch pointcloud_preprocessor ring_outlier_filter.launch.xml
ros2 launch pointcloud_preprocessor ring_passthrough_filter.launch.xml
ros2 launch pointcloud_preprocessor vector_map_inside_area_filter.launch.xml
ros2 launch pointcloud_preprocessor voxel_grid_downsample_filter.launch.xml
ros2 launch pointcloud_preprocessor voxel_grid_outlier_filter.launch.xml

Notes for reviewers
None
Interface Changes

Remove all default values in declare_parameter() function
Create .yaml files for all used nodes.
Update .launch.xml file to import .yaml.
Create schema for each launch file.
Update README.md
Test build and launch successfully.

Effects on system behavior
None
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed  the contribution guidelines
[x] The PR follows the pull request guidelines

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.
After all checkboxes are checked, anyone who has write access can merge the PR.

@Ariiees
Thanks your contribution !
There seems to be some string + yaml issues according to pre-commit. Could you please address it?
@vividf
Please handle this when you have time (as a guideline, withing the week). Be mindful that this may cause virtual conflicts with your other PRs due to the inclusion of parameters

Thank you so much for reminding me! I have fixed the issues in my
"pointcloud_preprocessor" branch.
Best,
Yuxin
On Mon, Jun 10, 2024 at 9:15 PM Kenzo Lobos Tsunekawa <
@.***> wrote:

@Ariiees https://github.com/Ariiees
Thanks your contribution !
There seems to be some string + yaml issues according to pre-commit. Could
you please address it?
@vividf https://github.com/vividf
Please handle this when you have time (as a guideline, withing the week).
Be mindful that this may cause virtual conflicts with your other PRs due to
the inclusion of parameters
—
Reply to this email directly, view it on GitHub
https://github.com/autowarefoundation/autoware.universe/pull/7422#issuecomment-2159585944,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU5CVWVHYCULZUWF4ASOSWDZGZFT7AVCNFSM6AAAAABJDCDE6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZGU4DKOJUGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Ariiees
Apologies that the current pointcloud preprocessor doesn't have a launch file for each node, therefore it is required to have those launch files together with this PR, otherwise, the user can't run the single ros node by ros2 run pointcloud_preprocessor <node_name>
You can take a look at this PR https://github.com/autowarefoundation/autoware.universe/pull/7137/commits/4a828867f93aad70a4d6a2c125c161c98dc4f639 (especially the schema, param, and launch files).
To merge your hard work, you might need to provide more launch files (except the distortion correction node, and concatenation node as I am working on those nodes now) and make sure all of the launch files (including the previous one that I mentioned such as pointcloud_preprocessor.py  can work as expected.
Thank you again for your contribution. Please let me know if you have any questions :+1:
Vivid

@vividf
Thank you so much for your suggestion! I have reconfigured the .launch.py file. Make sure all parameters are imported correctly. I will proceed to write a launch file for each node!

@Ariiees
Please let me know when it is ready for review :)

@Ariiees
Please let me know when the PR is ready for review :)

@vividf I have added other launch files and tested them successfully on my side. Also add schema for each launch file. Could you test it again? Thank you!

Hi @Ariiees, let me know when the PR is ready for review. Thanks!

Hi @Ariiees, let me know when the PR is ready for review. Thanks!

Hi @vividf. Thank you so much for your time and suggestions. I have resolved the problems. Could you please check again? Thanks!

@Ariiees Thanks for your work.
I left some comments and commit suggestions.

For the commit suggestions, please double-check them. If you agree to the changes, click the button directly.
For the comments, please post the commit that fixed the issue in the specific block.

I also found some files that were missed

schema file for the pointcloud_accumulator_nodelet
launch file for the crop box node

@vividf
Thank you again for your double-checking! The comments were resolved accordingly, and the branch is synced to the latest main. Could you please check them again?

@Ariiees Thanks for your work. I left some comments and commit suggestions.
* For the `commit suggestions`, please double-check them. If you agree to the changes, click the button directly.

* For the comments, please post the commit that fixed the issue in the specific block.

I also found some files that were missed
* schema file for the pointcloud_accumulator_nodelet

* launch file for the crop box node

Additionally, please rename all of the parameter files. For instance, voxel_grid_outlier_filter_param_file.param.yaml to voxel_grid_outlier_filter.param.yaml. Changes also need to be applied to the content in those launch files.

@Ariiees
Thanks for your work, I left some comments.
Please make sure that the pointcloud preprocessor compiles successfully and test all of the launchers again :)
Vivid

@Ariiees
Since I couldn't build the pointcloud preprocessor successfully due to some errors, I fixed them directly to save both of our time :)
According to the autoware parameter, the previous changes I made (from your uint16_t to my uint32_t) are wrong, so I modified all  uint16_t and uint32_t to int64_t.
Additionally, could you delete both polygo_remover.launch.py and preprocessor.launch.py, since the way you wrote them is a bit different from how we load parameters and it is hard to modify them? I will create a PR for those files which will be merged with this PR.
Note that there are some comments above that can only fixed by you, Thanks.

@Ariiees
Let me know after you solve some small errors listed above, I think we are close to merge this PR  :+1:
Note that there are conflicts between the main branch, please be careful this time :)

@Ariiees
I noticed that after you force-push the branch, there are many conflicts you need to solve.
If you feel it is too hard to solve them, you can close this PR and create a new PR.

@Ariiees I noticed that after you force-push the branch, there are many conflicts you need to solve. If you feel it is too hard to solve them, you can close this PR and create a new PR.

@vividf Yes.... I made a stupid mistake in the last update; I've tried to rebase to the current main and solve the conflict (shown in the current pr). Sorry for the trouble! I will keep the current point cloud preprocessor folder and clone the latest main to create a new RP (will also update the website address in Google sheet)


Fix client creation error when one of the auth infos are invalid

Signed-off-by: Utkarsh Srivastava<EMAIL_ADDRESS>Description
This PR fixes https://github.com/layer5io/meshery/issues/2134
This PR adds a filtering function which removes invalid authentication infos from he kubeconfig. It will now fail iff all of the auth infos turn out to be invalid.
Notes for Reviewers
This fix is added here because the issue is that certificate files may be accessible to the meshery server but may not be accessible to the meshery adapters hence the error would arise again. Filtering the kubeconfig within the adapters will allow each adapter to individually verify if the certificates are accessible to it or not.
Signed commits

[x] Yes, I signed my commits.

@leecalcote, @kumarabd please review. Can't seem to request review in this repository.

I will make an adapter library release and upgrade one of the affected adapters as a test.


Move npm development dependencies to devDependencies

I think all dependencies inside package.json should be moved to devDependencies as they are required to build, test, and manage Crafty code but they're not required by the Cratfy engine itself.
See https://github.com/craftyjs/Crafty/pull/568#issuecomment-26970762

AFAICT this was resolved at some point -- everything is now in devDependencies.  So closing!