FR: type=device actions=managedevice-delete:true - decommission a serial

Is your feature request related to a problem?

FR: delete a FW serial on all places within a Panorama configuration
Describe the solution you'd like

type=device devicetype=manageddevice actions=displayreferences
is displaying all places where a serial# is configured within the configuration file.
delete all references and XML node entries.
Describe alternatives you've considered

Policy entries of Serial# can be right now done with:
type=rule ruletype=any actions=target-set-any location=any outputformatset=setcommands.txt
but this is only taking care of a specific part of a Panorama configuration file
Additional context

automate decommission a managed device serial#

Oh, count me in for this.  I only use targets in Shared (and soon some DG Hierarchies), so I just run a target has filter and for the remove a target-remove.
I also have standalone DGs & Templates for each firewall or cluster - would this clean those up as well?
I actually have a cluster/DG/Template to decom right now if you'd like a test subject.  I can hold onto it (I'm not in a rush as I have plenty of things to do).

bump
Just following up - do you have a rough idea of when you might incorporate this FR?
I'm in no rush - I have a process now that's somewhat automated for targeted rules (Shared and DG Hierarchies) and manual for everything else.
Thanks!


Resolvable not supported FederationV2 when checking the subgraph

I started up to generate FederationV2 compatible subgraphs but now hive-cli started up to return the following:
Unknown argument resolvable on directive @key
Any idea on this ?

It's probably because it's not backwards-compatible with Federation v1, so unfortunately you need to use
https://docs.graphql-hive.com/features/external-schema-composition#pre-built-docker-image to compose subgraphs for Federation v2. It will be supported natively soon.

Great. Thanks. That's the only issue i'm having. Otherwise just removing this attribute is functional


Performance discussion

At first I want to thank you for sharing such a useful tool, makes a night and day difference in my use case.
That said, I'm very curious about its performance, in my test, single connection performance (throughput and CPU usage) is roughly the same compared to udp2raw, while wireguard (inherently at about the same throughput with marginal differences) is consuming significantly less. One might argue wireguard works in kernel so there's less userspace-kernel overhead, but I also compared boringtun, which is cloudflare's userspace wireguard implementation, it still consumes significantly less CPU compared to phantun/udp2raw.
That's quite surprising to me since wireguard also does encryption/decryption while phantun doesn't.
One thing I could think of, fake-tcp has to maintain fake tcp connections statefully, wireguard doesn't have/need this, if this is indeed the main CPU hog, we could possibly use a simple-fake-tcp method: do not fake connections, just send packets statelessly, obviously this would need both sides to do stateless NAT thus harder to deploy, but might be beneficial in some use cases.
What do you think?

Thanks for the reply.
I didn't mean phantun + wireguard vs wireguard, I meant phantun alone vs wireguard, while working together, phantun alone uses more cpu than wireguard.
"TCP masquerade will always be stateful as there are sequence number and so on that needs to be kept track of." - if we want to fake TCP properly, but I'm suggesting the other way.

@Jimmy-Z If that is the case then maybe you can even just use some eBPF magic to modify the L4 headers directly. But this is not something Phantun wants to solve as we do care about NAT traversal as the primary use case.


drop redundant type parameter

This PR deletes one token. Currently main contains this line:
Base.promote_typejoin(::Type{Either{<:Any, R}}, ::Type{Either{<:Any, R}}) where {L, R} = Either{<:Any, R}

The type parameter L is never bound, which can cause performance problems. This PR fixes that.

Codecov Report

Merging #3 (41f5a7c) into main (f3d74c6) will increase coverage by 0.05%.
The diff coverage is 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main       #3      +/-   ##
==========================================
+ Coverage   84.77%   84.82%   +0.05%
==========================================
  Files           8        9       +1
  Lines         289      290       +1
==========================================
+ Hits          245      246       +1
  Misses         44       44

Impacted Files
Coverage Δ

src/promote_type.jl
83.33% <100.00%> (ø)

... and 1 file with indirect coverage changes


Generate submitted file

We can only see the accuracy of validation set, when we run
 python launch.py -c expts/02_ek100_avt_tsn.txt -l -t.
Can you tell us how to generate the submitted file for the challenge ek100?

Please see instructions here: https://github.com/facebookresearch/AVT/blob/main/docs/MODELS.md#epic-kitchens-100-testchallenge-submission

Please see instructions here: https://github.com/facebookresearch/AVT/blob/main/docs/MODELS.md#epic-kitchens-100-testchallenge-submission

It seems that the script is used to fuse the results of different model. How can I generate the submitted file using only one model, such as "02_ek100_avt_tsn_test_testonly.txt"?  ''python launch.py -c expts/02_ek100_avt_tsn.txt -l -t'' can only evaluate the model in the validation set?

Hi, apologies for the delay. You can always pass in a single file with weights = 1 and it will generate outputs for that single file.
Also since the test set is not public, the code itself can only do evaluation on the val set. For test results you need to submit to the evaluation server.


Enhance tag matching/describe: tag_match + tag_exclude

ATM tag_prefix serves at least two roles
$> git grep -e tag_prefix | grep -e startswith -e --match
src/git/from_keywords.py:        if ref.startswith(tag_prefix):
src/git/from_vcs.py:                                     "--match", "%s*" % tag_prefix],
src/git/from_vcs.py:        if not full_tag.startswith(tag_prefix):

so to pass to git describe --match to select tags, and then to strip that prefix from the tag.  That works quite nicely for a good range of use cases, but fails in a range of others: see #105, #182 ( probably more, yet to fish), which seems to boil down
I think that we could address majority of use cases if we allow for

tag_match so we get

src/git/from_vcs.py:                                     "--match", "%s%s*" % (tag_prefix, tag_match)],

to be able to more precisely match for desired tags whenever desired, but not demand stripping that away (as if now tried to provide glob in tag_prefix as I ignorantly suggested in #105)

tag_exclude (multiline with multiple entries allowed, .strip before use) so we pass --exclude <tag_exclude> option(s) to git describe.

I have not analyzed yet how it would work for src/git/from_keywords.py or it would need to be git specific.
WDYT @warner, @effigies (doh -- we need to setup teams), @nolar, @benjwadams, @jwodder ?
edit 1:
alternative to tag_exclude could be git_describe_options which would default to all the other options there ATM, and be allowed to be tuned or replaced. For tuning, could be exposed via string comprehension so with
git_describe_options = %(git_describe_options)s --exclude '[^0-9]*'

I would just add the desired --exclude.  But it would give me ability to override all the rest (e.g. I do not like --all since I prefer git default and do not like to consider non-annotated tags which shouldn't be used for releases. With github releases though those became prevalent :-/)

I'm failing to understand the use cases here.
#105 I get, and it looks like a sensible solution to the problem. I'm inclined to rebase that one myself and just get it moving.
I completely fail to understand the problem in #182. I think #105 would prevent v0.1 from being considered, but presumably git describe wouldn't be reaching as far back as v0.1. I've asked them to clarify...
What is the --exclude solving in DANDI's use-case? Could you describe it with a series of tags?

Pushed #105 replacement to #256.

What is the --exclude solving in DANDI's use-case? Could you describe it with a series of tags?

(git)lena:~/proj/dandi/dandischema[master]git
$> git tag
0.0.0
0.1.0
0.1.1
0.2.0
schema-0.4.0

$> git describe
schema-0.4.0

$> git describe --exclude '[^0-9]*'
0.2.0

ref on more discussion etc: https://github.com/dandi/dandischema/pull/19#discussion_r640049802

Okay, so --match "{prefix}[0-9]*" covers this use case. The only question is whether anybody would ever want "schema-0.4.0" to be a real version.

then they say tag_match = schema-[0-9]*  ;-)


Making more clear for Coinkite

Well the documentation link doesn't work anymore. Have any proof of Coinkite supporting sms & hardware?

We even support Paper OTP :)
Here https://coinkite.com/settings/2fa

Okay so I see Software, SMS and paper there. But hardware?

You can add smart cards to be Mutlsig Co-Signers http://blog.coinkite.com/post/116127008376

Carl, paper is "hardware"☺
@nvk is there docs link we can use?

The docs are on the 2FA setup internal page https://coinkite.com/settings/2fa but some info here too https://coinkite.com/iforget

Paper is considered hardware? That's odd...
Okay then

Even though we have smart cards as co-signing for transactions which is essentially 2 factor authentication because you are using a secondary system to authenticate an action, the idea of hardware 2FA is that is a device (chip, paper cards, etc) that provide offline form of OTP/TOTP

Carl, would you say it's "software"?

I would say it's a category we haven't yet added.

We've been calling it hardware. At least, that's what we went with when I ran into it with Coinify (#1023), though I did specify using the exception flag.

Okay


Test PR to test PR Labeler

Fixes

Reverting removes label

trying sync-labels=true

PR Labeler with
#         sync-labels: true

removes labels as well


Create Self Digital Signature Certificate

for Office 2016 C2R edition which is installed on windows 10.

@RAJU2529 -- If you want a particular/specific scenario covered in this documentation, please leave us "content feedbacK" and we will evaluate the request to see if it is an appropriate addition to the article. In this case, creating a self-signed certificate doesn't really fit the purpose of this article. And you can't link out to an unknown external location like you did (for the screenshot).


API: Use u8 instead of hex str

This first commit only changes the i part of the EdhocInitiator for review.
Apart from the obvious API break, the weirdest part here is the classify loop. @geonnave, how would I best sequence this against your pending changes that remove the hacspec arrays? Is there a branch I can build this on, should I hold it off for a few days, or should I just wrap the classify loop in a one-shot compatibility wrapper that doesn't need to be pretty, is used for all the conversions where the un-hexification conveniently hid the classify before, and wait for it to be removed later?
Contributes-to: https://github.com/openwsn-berkeley/edhoc-rs/issues/99

I think the proposed change is beneficial, give me one more day and I will report back on the state of the hacspec cleaning.

This is targeting remove-hacspec now, given that that's the way forward and much easier with this PR -- every change made against main would need manual rebasing after #106 is merged anyway. I'm having trouble building locally with the remove-hacspec branch so far (from psa-crypto-sys); until I've managed to resolve that, I may be a bit force-pushy while I iron out bugs CI finds.

Responding to some comments:

I'm having trouble building locally with the remove-hacspec branch so far (from psa-crypto-sys)

Just to make sure, this is how I call it as of today in the remove-hacspec branch: cargo test --package edhoc-rs --package edhoc-crypto --package edhoc-ead --no-default-features --features="cb-psa, ead-none" --no-fail-fast.
You could also try cb-hacspec instead.

There is trouble with f-star generation. Could you help me out here?

Don't worry about it, we will likely skip this test from CI until the hacspec side is adjusted.

@chrysn remove-hacspec has been merged, targeting main should be fine now :)

Regarding the compilation for PSA, I've easily made it work on Ubuntu but not on MacOS. As a result, when I'm on the Mac, I cargo test it within a multipass Ubuntu VM.

The changes look great! Some notes:
C example
I don't know if I got it right but should it be updated as follows?
Use
static const uint8_t ID_CRED_I[] = {0xa1, ... };

Instead of
static const uint8_t ID_CRED_I[] = "a104412b";

Impacts on hax
@W95Psp could you give a quick look? Here's one example of the kind of change we're looking at:
fn compute_mac_2(
    prk_3e2m: &BytesHashLen,
    id_cred_r: &BytesIdCred,
    cred_r: &[u8],  // <--- this type changed from `&BytesMaxBuffer` (note that `type BytesMaxBuffer = [u8; MAX_BUFFER_LEN]`)
    th_2: &BytesHashLen,
) -> BytesMac2 {

Good catch on the C side; fixed. (That's why I like statically typed languages :-D).

Looks good to me! The only unknown is the use of &[u8] with hax, but since hax only targets lib/src/lib.rs, that means only cred_X are impacted, which would be easy to modify if needed.


Sensors for system variables show hash sign in HA

custom_component/hahomematic version (if applicable):
0.13.2
Home Assistant version (if applicable):
2021.12.7
CCU version:

Model (CCU2/3, Raspi3/4, NUC, ProxmoxVE, ...): Raspi3
OS (Original, RaspberryMatic, debmatic/...): RaspberryMatic
Version: <IP_ADDRESS>11218

Problem-relevant configuration:
Do you use tls? yes
Do you use callback? no
Do you use username and password? yes
Which interfaces do you use? RF / HmIP
Describe the bug
I have activated "aktiviere Sensoren für Systemvariablen" (just for testing, no use case so far). The sensors are all shwon with an hash sign at the end???

To Reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
Additional context

Yes that is correct.
Systemvariables are just Strings that have no unit.
To make them displayable in charts the need a unit. That's why i selected a #.
You can customize it in HA, if you want an other unit.

Ok fine.

But maybe we should make the the Entity-ID's more unique e.g. sensor.alarmmeldungen is not very unique.
Better to prefix the sensor name with the name e.g. in my case  sensor.raspberrymatic_alarmmeldungen. Or what do you think?

There is a unique_id in the backgroud, so you can change the entity_id (within sensor domain) to whatever you want.

Just one more question regarding sensors for system variables.
RaspberryMatic WebUI shows the following variables:

But in HA only those are visible:

What about DutyCycle for example? This would be nice to have.

Which RF-Module do you use?

Uhhh ... I don't know. I ordered a ready build device 2018 from Homematic-Guru.de.
Does i really mater? The system variable is shown inside RaspberryMatic WebUI and seems alive ...

Check your ccu device list, if there is a dedicated device for your rf-module.

No here is no extra device shown.

Then i guess you have the old rf-module.
And yes, it matters, because the new module is a dedicated device with real sensor.
So instead of relying in SV device sensors are much better.
But i didn't know that the old one is not available as a dedicated device.

Ok. I was so naive to think it a system variable and just shows up in HA :-(

As my Python skills are a bit limited I fired up some curl magic to call the JSON-API service SysVar.getAll.
This is what is called in client.py#L513, right?
This is the result I get, which although includes the DutyCycle. Is there some magic I missed why only "Alarmmeldungen" and "Anwesenheit" is shown in HA?
{
  "id": 0,
  "version": "1.1",
  "result": [
    {
      "id": "40",
      "name": "Alarmmeldungen",
      "type": "NUMBER",
      "unit": "",
      "value": "0",
      "channelId": "65535",
      "minValue": "0",
      "maxValue": "65000",
      "isLogged": false,
      "isVisible": true,
      "isInternal": true
    },
    {
      "id": "950",
      "name": "Anwesenheit",
      "type": "LOGIC",
      "unit": "",
      "value": "true",
      "channelId": "65535",
      "valueName0": "nicht anwesend",
      "valueName1": "anwesend",
      "isLogged": false,
      "isVisible": true,
      "isInternal": false
    },
    {
      "id": "5025",
      "name": "DutyCycle",
      "type": "NUMBER",
      "unit": "%",
      "value": "20.000000",
      "channelId": "65535",
      "minValue": "-1",
      "maxValue": "100",
      "isLogged": false,
      "isVisible": true,
      "isInternal": false
    },
    {
      "id": "5165",
      "name": "DutyCycle-Alarm",
      "type": "ALARM",
      "unit": "",
      "value": "",
      "channelId": "65535",
      "valueName0": "nicht ausgelöst",
      "valueName1": "ausgelöst",
      "isLogged": false,
      "isVisible": true,
      "isInternal": false
    },
    {
      "id": "41",
      "name": "Servicemeldungen",
      "type": "NUMBER",
      "unit": "",
      "value": "1",
      "channelId": "65535",
      "minValue": "0",
      "maxValue": "65000",
      "isLogged": false,
      "isVisible": true,
      "isInternal": true
    },
    {
      "id": "5335",
      "name": "WatchDog-Alarm",
      "type": "ALARM",
      "unit": "",
      "value": "",
      "channelId": "65535",
      "valueName0": "nicht ausgelöst",
      "valueName1": "ausgelöst",
      "isLogged": false,
      "isVisible": true,
      "isInternal": false
    },
    {
      "id": "7357",
      "name": "WatchDog: no-internet",
      "type": "ALARM",
      "unit": "",
      "value": "false",
      "channelId": "65535",
      "valueName0": "nicht ausgelöst",
      "valueName1": "ausgelöst",
      "isLogged": false,
      "isVisible": true,
      "isInternal": true
    }
  ],
  "error": null
}

Thanks. Are the WatchDog* variables although filtered out?

Only from sensor. It's in the hub.
EXCLUDED_FROM_SENSOR = [
"Connection",
"pcCCUID",
"RF-Gateway-Alarm",
"WatchDog",
]
EXCLUDED = [
"CarrierSense",
"OldVal",
"Servicemeldungen",
]

I would suggest to leave it up to the user to disable the sensors like e.g. WatchDog. On the other side you didn't exclude those energy tracking variables (I deleted those alerady on the CCU).

It's not only energy tracking. There are also SVs from the weather station, that show the last day's value, which are not available by the devices itself.
If Watchdog is not filtered out.

Hi,
I would like to suggest to use the the unit attribute from the system variable as the unit_of_measurement e.g.
    {
      "id": "5025",
      "name": "DutyCycle",
      "type": "NUMBER",
      "unit": "%",
      "value": "20.000000",
      "channelId": "65535",
      "minValue": "-1",
      "maxValue": "100",
      "isLogged": false,
      "isVisible": true,
      "isInternal": false
    },

If the unit is empty than do not set  unit_of_measurement for the sensor. This way the unit can be controlled by the user via CCU and is preserved and not overwriten by a # sign.

What do you think?
Best regards
Ingo

As successor of pyhomematic this integration supports CCU and Homegear.
Homegear does not provide unit values, only key names and values.
So common to both is key and value.
The only sysvars on my system with a unit are dutycycle and carriersense_level, but these sysvars are only relevant if you have an old rf-module, because the new module is avalaible as a dedicated device.
Just customize the entity in HA, like i do.

Forgotten about Homegear sorry.

No problem.

@SukramJ Closed, but related,

You can customize it in HA, if you want an other unit.

The unit on the left stays in #. Is this because recording stated with % and at the time only % are displayed, it will change to % or do you have another idea?

sensor.hmip_status_dutycycle:
  state_class: measurement
  unit_of_measurement: '%'

Good Question.
Go to Developer Tools -->statistics.
Are there any problems reported?

Do you use a CCU3?

No.

Good Question.

@SukramJ Nur weil ja alle sysvars keine Einheiten haben und es daher ja sein kann, dass nach eigener Änderung ab und an wieder die Frage kommt, bzgl. meiner Beobachtung von oben.   Daher war es vorher ewig # und nun nach purge der ältesten Werte die neue %.

Was ebenso auftritt und aber auch ein HA-Fehler/Feature sein wird. Auch im Hover der Werte wird diese älteste aller Einheiten auch für neue Werte genommen, selbst wenn diese eigentlich schon mit neuer Einheit im Recorder sind.
Also für beides: Warten oder db löschen. Dann stimmen Hover und y-Achse.

This ticket can stay closed. See

Did you look into state_class?
Also, fancy to cast Alarmmeldungen and Servicemeldungen to int? Sounds minor but feels relevant.

i needed a solution for sensor and number, and number doesn't support state_class.
That's behind:

Better differentiate between float and int for sysvars

I don't care about single sysvars.

I can see that now 👌  https://github.com/danielperna84/hahomematic/compare/1.7.1...1.7.2
Great! Thanks


Alerts stuck open when new alert queued as old one closes

Creating lots of alerts can cause one of them to get stuck. I should investigate why that is.
Update:
This happens if you open a new one before an old one closes while an old one is in the process of closing. Wonder why that is!
Another update:
Okay, so, it never unmounts when this happens, and a new one never mounts. There needs to be some sort of delay to ensure that the old one unmounts, or a better guarantee of the callback being called when the animation is over.
Third update:
No hook exists when using ReactCSSTransitionGroup. There's an issue here describing an API that would fix it: https://github.com/facebook/react/issues/5914
In the meantime, I think I'll need to implement my own custom CSSTransitionGroup on top of ReactTransitionGroup, which is a bit of a bummer.
Another update:
This is necessary because the mount/unmount hooks are used for closing the alert and starting the next one

It turns out that I needed the transition enter event as well, since re-mounting was unreliable. I was using the mount event to know when to schedule the alert for removal. The transition enter event is better, too, since the timeout won't take into account the duration of the animation. Pretty cool.


Data function gets default value of context

Hi!
I have the next router config:
const routes = [
  {
    path: "/sign-in",
    component: () =>
SignIn

  },
  {
    path: "/",
    component: () => (
      <NumberContext.Provider value={777}>
        <Outlet />
      </NumberContext.Provider>
    ),
    children: [
      {
        path: "home",
        component: Home,
        data: homeDataFunction
      },
      // ...other routes
    ]
  }
];

I want to init all app related contexts only in case authenticated user.
But in data function homeDataFunction I get a default value of context. Looks like because it doesn't see Provider.
Link to repro
It works fine in 2 cases:

in Home component itself (via useContext)
if I wrap the whole router with Provider but that's not valid way for me.

Thanks in advance!

The challenge here is data functions need to run in parallel regardless of the nesting so they are hoisted out of the flow since we need to be able to call nested ones before we've "rendered" where the children would be in the flow to avoid waterfalls. In so generally Provider has to be above the <Routes> definition. Given the way this parallelized fetching works I don't see a fix for this. Rather different ways to work around this.
They do still run in order though. One thing that can be leveraged though is that the data functions pass the parent's data function return to the next child, so it is possible to create dependencies hierarchically this way. In your case it seems like the desired behavior is to create a provider only once in the logged in portion of the app. Would it be possible to basically use the routeData and the context mechanism to get the auth data. Ie.. in the data function for "/" do the auth and leverage the fact descendants can access it?

Hi, @ryansolid!
I see your point and it definitely seems that it's impossible to make Data Functions capable of handling data fetching from the service layer with its own business logic inside.
But maybe it is possible to give more lifecycle hooks for the each specific route?
For example, if there was a possibility to have some kind of interceptors for each route that would handle cases of manual redirection before data and script fetching yet to be initialized. It would be possible to avoid usage of the auth service in the context in the first place.
So the resolving of the rout would look like Interceptor -> Data Function -> Component Rendering. Interceptor also can provide its data to the data function allowing more flexible data fetching depending on the resolved state of the interceptor.
It might look like:

type InterceptorReturn<T> = {
    allowed: boolean;
    state: T;
};

type InterceptorFunc = (input: {params, location, navigate, data, state}) => InterceprotReturn;

It appears that inability of data functions to be connected to the applications contexts narrows down their use cases significantly, which is really pity because it is really awesome feature 😄
What do you think about this?

I did not mean to bring functionality that will restrict developers in their ways to organize application architecture.
The problem I see is that Data Functions are not context aware, but data for the specific page as well as the page itself usually is context aware. If I am only able to initialize contexts on the top level of the application the whole point of the Dependency Injection is gone, because what is the point of having multiple contexts if I can only have them initialized on the top level?
On the other hand I can go with separation that you are suggesting (if I understood you right). Using the same an example with AuthService, I should initialize it on the top level and use it as a context inside Solid Components but in data functions I should have some kind of 'waterfall' context specific for the data functions. This means that I should support two context in the same time which is not great.
My suggestion about Interceptors was about having an ability to put some logic between initialization of the navigation process and triggering already existing logic of parallel data fetching and script loading. Something like an ability to wrap a route with a component that would be context aware.
As you said in the initial answer that we don't have an ability to make Data Functions context aware so I thought that we can have a piece of context aware code before data and script fetching has taken place.
In addition, even though I have an ability to navigate to another page in the data function I have no ability to prevent script loading that has been started already when the data function is executed. This is the reason, why in our project we decided to implement ProtectedRoute as a wrapping component instead of data function.

The sentiment still stands but I think with our change towards preload functions it is clearer how the pattern fits now. ProtectedRoute is the approach here as data functions are just preload functions and are auxiliary.
I'm going to close this one as it refers to an older architecture we no longer have.


Can MAVSdk support set ekf origin?

Hello, I have a homework which needs to fly multiple UAVs, So I plan to build a global NED Coordinate.
But when a vehicle starts to takeoff, It's current ned postion is ( 0, 0, 0 ).
I want to modify the current NED position by setting ekf_origin.

Is there a mavlink message that is implemented in PX4 and that does that?

Is there a mavlink message that is implemented in PX4 and that does that?

Arrording to
https://github.com/ArduPilot/MissionPlanner/issues/1901,
I guess Mavlink should have this message.

MAVLink messages are defined here: https://mavlink.io/en/messages/common.html
Next step is to find which one you want (if it exists) :wink:

Looks like it would be this one: https://mavlink.io/en/messages/common.html#SET_GPS_GLOBAL_ORIGIN
Which even seems to be implemented by PX4:
https://github.com/PX4/PX4-Autopilot/blob/5eddf32cd38f25e385a1a171319e4e08a3a4a4dc/src/modules/mavlink/mavlink_receiver.cpp#L1188-L1211

Oh we already have a getter for that! https://github.com/mavlink/MAVSDK/blob/main/src/plugins/telemetry/telemetry_impl.cpp#L2139

@julianoes @JonasVautherin , thanks for your help. Now I think mavlink message SET_GPS_GLOBAL_ORIGIN or mavsdk api TelemetryImpl::get_gps_global_origin_async may be used to set ekf_origin.
Next, I will test this api( get_gps_global_origin_async ), and write my result.
Thanks your help.

The setter needs to be implemented.
See here, how a feature can be added: https://mavsdk.mavlink.io/main/en/cpp/contributing/plugins.html#add-api-to-proto

@julianoes  Would that go into the action plugin?

Yes. I'd say so.

Hello! I'm trying to implement this change request for some personal test.
I wonder if this message should be in mocap instead of actions... also, should it be a sync method?

I think action is ok. I'd do both if both are useful.


3.0.4 moving objective tracker over mini map on login or reload

Using the Modern preset layout

When WarpDelete 3.0.4 is installed, upon logging in or re-loading, my objective tracker overlaps my map

Downgrading back to 3.0.3 fixes the issue and objective tracker renders correctly underneath mini map

I think I know what causes this. If I provide you with a branch with a potential fix, would you be able to test it?

Also, @Numynum could you have a look at this? I suspect the reparenting to UIParent causes this, or maybe we need to also store and restore the position when un-hiding the tracker frame.

ah yeah, didn't really count on the ShowBlizzardObjectiveTracker code running before the HideBlizzardObjectiveTracker 🙂
but I have a simple enough fix in mind (I can't reproduce the problem though, so if @aruberto can test it, that'd be good)
will send a PR in a sec

FWIW, positioning should generally be unaffected, presumably it's only on initial loading, when the quest tracker position is loaded from edit mode or an addon, where it sets the position relative to the parent
but once the position is set, changing parents has no impact
so as long as we don't mess with the parent until actually hiding the frame, all should be well
TL;DR,I don't see any point storing and restoring the position 🙂

Ok, gotcha on the positioning bit. Still don't understand how the Show code could run first, but let's see if this fixes it. @aruberto, can you test the branch from the PR? It's a pretty small patch, so you could even just copy the patch into your installation.

WarpDeplete:OnEnable() calls WarpDeplete:Hide() which calls WarpDeplete:ShowBlizzardObjectiveTracker() during the initial loading screen

Applying the change from commit https://github.com/Numynum/WarpDeplete/commit/7359599601d1364fc431a786e4700f3f22d6eb41 seems to work

Fixed in #81, 3.0.5 includes this.


no plugin found error after histoire dev

Describe the bug
$ histoire dev
file:///Users/igormakowski/Documents/Projects/rigtch-music-www/node_modules/histoire/dist/node/stories.js:70
        throw new Error(`No support plugin found for file ${absoluteFilePath}`);

Error: No support plugin found for file /Users/igormakowski/Documents/Projects/rigtch-music-www/components/example.story.vue

Reproduction
histoire.config.ts
import { defineConfig } from 'histoire'
import { HstNuxt } from '@histoire/plugin-nuxt'

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

nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@pinia/nuxt', 'nuxt-windicss'],
  css: [
    'vuetify/lib/styles/main.sass',
<EMAIL_ADDRESS>  ],
  build: {
    transpile: ['vuetify'],
  },
  vite: {
    define: {
      'process.env.DEBUG': false,
    },
  },
})

System Info
System:
    OS: macOS 13.0
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
    Memory: 36.07 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.12.0 - ~/.nvm/versions/node/v18.12.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.12.0/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.0/bin/npm
  Browsers:
    Chrome: 107.0.5304.110
    Safari: 16.1
  npmPackages:
    @histoire/plugin-nuxt: ^0.11.7 => 0.11.7
    @vitejs/plugin-vue: ^3.1.0 => 3.1.0
    histoire: ^0.11.7 => 0.11.7

### Used Package Manager

yarn

### Validations

- [X] Follow our [Code of Conduct](https://github.com/histoire-dev/histoire/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/histoire-dev/histoire/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://histoire.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/histoire-dev/histoire/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/histoire-dev/histoire/discussions).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

I think you need vite.config as well

Hi there, I am playing with the configuration, and it seems that the HstNuxt keeps their owne nuxt config, since it ignores all my nuxt.config.ts if so, is it possible to use my config into histoire? Thnaks :pray:


Resubmitting PR for issue 966: Added HeliumStreamLogger + minor improvements

Description

Motivation and Context

How Has This Been Tested?

Checklist:

[ ] I have submitted a CLA form
[ ] If applicable, I have updated the documentation accordingly.
[ ] If applicable, I have added tests to cover my changes.

Current coverage is 100% (diff: 100%)

Merging #41 into master will not change coverage

@@           master   #41   diff @@
===================================
  Files           1     2     +1
  Lines         133   144    +11
  Methods         0     0
  Messages        0     0
  Branches        0     0
===================================
+ Hits          133   144    +11
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update 913e844...92caa4e


Update to razzle 4 (still with webpack 4)

Based on #2351, but without trying to upgrade to webpack 5 at the same time.
What does razzle 4 give us?

updated dependencies
a path to using webpack 5
an option to extract css in dev mode, which can avoid the flash of unstyled content

To do:

[x] fix tests

[x] the generator acceptance test is failing because it can't find @plone/volto/start-server in build/server.js

[x] determine and document any updates needed to addons --> looks like the old razzle plugin format (modify function) is still supported, with a warning
[x] try it with a real project
[x] document how to update projects

[x] update webpack config for compatibility with postcss 8
[x] update razzle plugin format
[x] add cache to .gitignore
[x] use --env=jsdom instead of --env=jest-environment-jsdom-sixteen
[x] replace jest-css-modules transform with identity-obj-proxy

[ ] after merging this:

[ ] release @plone/scripts and update the version used by volto itself, so we don't require 2 different versions of razzle

@sneridagh @tiberiuichim I think this is ready for another look. How do you feel about including it in volto 16, or should we wait? I've done some testing of this with a project using yalc and I think the risk from the changes in Razzle itself is fairly low, but perhaps there are adjustments needed for updates to its underlying libraries that I haven't found yet.

Sure! I'll give it a try, also @plone/volto-team if someone else can try it out also and provide feedback, it would be great!

@sneridagh @plone/volto-team Any feedback? I'm wondering if we can include this for Volto 16, or if I should put it on the backburner.

We talked about it yesterday, all in favor to onclude it in 16. Some of us we will try it out and give feedback, if all ok, we can merge!
I'll try it out in our latest project too.

@davisagli I tried in our last project and I can't make it work.
I even went and followed what the GHA does (project generator tests) and no luck either:
❯ yarn start
yarn run v1.22.17
$ razzle start
 WAIT  Compiling...

/Users/sneridagh/Development/plone/volto/testproject/node_modules/@plone/volto/razzle.config.js:234
  const { include } = options.webpackOptions.babelRule;
          ^

TypeError: Cannot destructure property 'include' of 'options.webpackOptions.babelRule' as it is undefined.
    at defaultModify (/Users/sneridagh/Development/plone/volto/testproject/node_modules/@plone/volto/razzle.config.js:234:11)
    at modifyWebpackConfig (/Users/sneridagh/Development/plone/volto/testproject/node_modules/@plone/volto/razzle.config.js:317:27)
    at /Users/sneridagh/Development/plone/volto/testproject/node_modules/@plone/scripts/node_modules/razzle/config/createConfigAsync.js:1023:22
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Any clue?
I'll try to rerun the test now (now shows green).

@davisagli ok, I was missing to yalc the missing @plone/scripts Now it works, and the build is still green.

@davisagli I guess that all boils down to have released an updated @plone/scripts version, since all add-ons rely on it.

@davisagli I did some tests, and I guess we could remove the hard dependency on razzle, and just left the babel-preset-razzle one. It will force us to update all add-ons anyways, but at least they will be more lightweight on install. They will need to update because of the hoisting. We must make sure only one set of versions of babel plugins are in place. We had a lot of problems with that and yarn over the years.
I can't really recall why I introduced it, I think that it was from the days we tried to make the project inside an add-on idea... which we abandoned in favour of npx @plone/scripts addon clone ....

@sneridagh Yeah, I think you're right

anything that would reduce ongoing babel dependencies pain is worth taking the initial "hit"

https://github.com/plone/volto/pull/3678 last one before merging.


Pantheon 7 updates 2022-10-10

Description of changes
https://github.com/NixOS/nixpkgs/issues/170361
pantheon.granite7: 7.0.0 -> 7.1.0
pantheon.elementary-gtk-theme: 7.0.0 -> 7.0.1
Closes https://github.com/bobby285271/what-changed/issues/9
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@ofborg test pantheon


Add io module and add save to collection

A first step towards enabling saving/reading in collections

[x]  Borrow from zarr's approach of writing a consolidated metadata file (.xcollection.json). This  "special" JSON file would be written in the root directory and will contain a list of "valid" keys/paths of xarray datasets within that root directory. This allows us to avoid listing everything within the root directory.
[x] Add .to_zarr(self, directory, **kwargs) method. directory would point to the root directory that contains .xcollection.json file
[x]  Add .to_netcdf(self, directory, *, mode: str = 'w', **kwargs) method
[ ] xc.open_collection(directory, **kwargs)  function: if directory doesn't contain .xcollection.json file, we raise an error and exit.
[ ] BONUS: make this functionality file-system agnostic via fsspec.

@andersy005 here it is! Feel free to leave comments/suggestions

@andersy005 I was able to implement all of those except for fsspec...

@andersy005 should we wait to review until I implement fsspec?

@mgrover1, my latest commit includes changes we discussed in last week's meeting. With these changes, I expect this to work with any fsspec compatible store.

Thanks @andersy005 !!


Uncaught fromParseResult: Parse failed at [.hs] (1:7): Parse error: EOF

[Enter steps to reproduce below:]

Create new empty Haskell source file
Write "module" and as soon as I write the white space character after module it throws this error

Atom Version: 1.5.4
System: Linux Mint
Thrown From: haskell-ghc-mod package, v1.11.1
Stack Trace
Uncaught fromParseResult: Parse failed at [.hs] (1:7): Parse error: EOF
At /home/user1/.atom/packages/haskell-ghc-mod/node_modules/atom-haskell-utils/hs/hs.min.js:283

undefined

Commands
     -1:31.5.0 core:backspace (atom-text-editor.editor.is-focused)
  3x -1:30.8.0 core:move-down (atom-text-editor.editor.is-focused)
     -1:23.5.0 ide-haskell:close-tooltip (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:23.5.0 autocomplete-plus:cancel (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:23 editor:newline (atom-text-editor.editor.is-focused)
     -1:18.5.0 autocomplete-plus:confirm (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:17.8.0 core:save (atom-text-editor.editor.is-focused)
     -1:11.6.0 core:move-right (atom-text-editor.editor.is-focused)
     -1:10.7.0 core:save (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:06.1.0 core:backspace (atom-text-editor.editor.is-focused)
  2x -1:05.2.0 core:save (atom-text-editor.editor.is-focused)
     -0:32.8.0 core:move-left (atom-text-editor.editor.is-focused)
     -0:31.2.0 core:save (atom-text-editor.editor.is-focused.autocomplete-active)
     -0:29.6.0 core:delete (atom-text-editor.editor.is-focused)
     -0:29.4.0 core:save (atom-text-editor.editor.is-focused)
     -0:02.8.0 core:delete (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "disabledPackages": [
      "racer",
      "build"
    ]
  },
  "haskell-ghc-mod": {
    "additionalPathDirectories": [
      "/opt/ghc/7.10.3/bin/ghc"
    ],
    "ghcModPath": "/home/user1/.cabal/bin/ghc-mod"
  }
}

Installed Packages
# User
autocomplete-haskell, v0.6.2
haskell-ghc-mod, v1.11.1
ide-haskell, v1.5.4
ide-haskell-cabal, v1.1.0
language-haskell, v1.7.3
language-idris, v0.4.3
language-rust, v0.4.6

# Dev
No dev packages

Thanks for reporting. Fixed in 1.11.2.


nixos/prosody: make module defaults comply with XEP-0423

Motivation for this change
The overall idea behind all these changes is to provide some sane defaults to make the module "just work" by default. We are trying to stay as close as possible from the meta XEP-0423.
It is now possible to be fully complient with this meta-XEP with a minimal setup.
As an illustration, I use the following configuration on my personal prosody instance to get fully compliant to the conversations test (https://compliance.conversations.m/server/chat.alternativebit.fr/):
prosody = {
      enable = true;
      admins = [<EMAIL_ADDRESS>];
      ssl.cert = "/var/lib/acme/home.alternativebit.fr/fullchain.pem";
      ssl.key = "/var/lib/acme/home.alternativebit.fr/key.pem";
      virtualHosts."chat.alternativebit.fr" = {
        enabled = true;
        domain = "chat.alternativebit.fr";
        ssl.cert = "/var/lib/acme/home.alternativebit.fr/fullchain.pem";
        ssl.key = "/var/lib/acme/home.alternativebit.fr/key.pem";
      };
      muc = [ {
        domain = "conference.alternativebit.fr";
      }];
      uploadHttp = {
        domain = "upload.alternativebit.fr";
      };
    };
  };

After seeing a few prosody nixos config in the wild, I'm confident this PR will make setting up prosody much easier for a lot of people.
The NixOS test has been updated to test this compliance through a VM test.
See the commit messages for more details.

Inlined commit messages:
Setting up a XMPP chat server is a pretty deep rabbit whole to jump in
when you're not familiar with this whole universe. Your experience
with this environment will greatly depends on whether or not your
server implements the right set of XEPs.

To tackle this problem, the XMPP community came with the idea of
creating a meta-XEP in charge of listing the desirable XEPs to comply
with. This meta-XMP is issued every year under an new XEP number. The
2020 one being XEP-0423[1].

This prosody nixos module refactoring makes complying with XEP-0423
easier. All the necessary extensions are enabled by default. For some
extensions (MUC and HTTP_UPLOAD), we need some input from the user and
cannot provide a sensible default nixpkgs-wide. For those, we guide
the user using a couple of assertions explaining the remaining manual
steps to perform.

We took advantage of this substential refactoring to refresh the
associated nixos test.

Changelog:
- Update the prosody package to provide the necessary community
  modules in order to comply with XEP-0423. This is a tradeoff, as
  depending on their configuration, the user might end up not using them
  and wasting some disk space. That being said, adding those will
  allow the XEP-0423 users, which I expect to be the majority of
  users, to leverage a bit more the binary cache.
- Add a muc submodule populated with the prosody muc defaults.
- Add a http_upload submodule in charge of setting up a basic http
  server handling the user uploads. This submodule is in is
  spinning up an HTTP(s) server in charge of receiving and serving the
  user's attachments.
- Advertise both the MUCs and the http_upload endpoints using mod disco.
- Use the slixmpp library in place of the now defunct sleekxmpp for
  the prosody NixOS test.
- Update the nixos test to setup and test the MUC and http upload
  features.
- Add a couple of assertions triggered if the setup is not xep-0423
  compliant.

[1] https://xmpp.org/extensions/xep-0423.html

We are leveraging the systemd sandboxing features to prevent the
service accessing locations it shouldn't do. Most notably, we are here
preventing the prosody service from accessing /home and providing it
with a private /dev and /tmp.

Please consult man systemd.exec for further informations.

Things done

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

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

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

CC: @fpletz @globin @andir @florianjacob @flokli

@GrahamcOfBorg test prosody

I have a remaining question: I'd like to provide the user with an example let's encrypt setup.
Something along the lines of
security.acme = {
    email =<EMAIL_ADDRESS>    acceptTerms = true;
    certs = {
      "your.domain.com" = {
        webroot = "/var/www/your.domain.com";
        email =<EMAIL_ADDRESS>        allowKeysForGroup = true;
        group = "sslcertgr";
        extraDomains."chat.domain.com" = null;
        extraDomains."upload.domain.com" = null;
        extraDomains."conference.domain.com" = null;
      };
    };
  };

Where should I do this? I first thought about adding an example setup in the nixos manual, but I'm not sure people will end up reading it. Do you have any idea about were to put that?

Side note: I just realized @mmilata has been bumping prosody to 0.11.5 in the meantime (took me quite some time to fix the nixos test)! Will remove this commit in a sec.

Thanks a lot for doing this! I really like how this also makes the prosody module much more composable.
It's now also very easy to define mucs, which can be reused by things like https://github.com/NixOS/nixpkgs/pull/82920.

Where should I put this?
You might just want to add a nixos/modules/services/networking/prosody.xml containing some documentation, as well as the examples you posted in this PR.

As per suggested by @flokli, I added a Prosody section to the NixOS manual in df52c29 explaining how to perform a basic setup.
You can use nix-build nixos/release.nix -A manual.x86_64-linux && firefox result/share/doc/nixos/index.html to generate the doc.

Thanks a lot for all the nice work in here! :+1:


How to enable the exit-node function in this installation method? I followed the configuration of other tutorials online and used the tailscale up -advertise-exit-node command to enable it. It also showed that it was enabled, but the client could not use the exit function of the node.

How to enable the exit-node function in this installation method? I followed the configuration of other tutorials online and used the tailscale up -advertise-exit-node command to enable it. It also showed that it was enabled, but the client could not use the exit function of the node.

From the tailscale perspective, that would be it. As long as the admin panel shows it to be enabled, it is.
When you say the client could not use the function, is it unable to select the node as an exit node, or is it selected but no traffic flows through? If it is the former, that would be an issue with the tailscale client/admin panel config, if it is the later, that would be firewall configs on OpenWRT.

From the tailscale perspective, that would be it. As long as the admin panel shows it to be enabled, it is.
When you say the client could not use the function, is it unable to select the node as an exit node, or is it selected but no traffic flows through? If it is the former, that would be an issue with the tailscale client/admin panel config, if it is the later, that would be firewall configs on OpenWRT.

The official control panel shows that the exit node function is on, and the Android client can also start and select the exit node normally, but there is no traffic. There is no manual configuration of the firewall in your configuration file, and I did not configure the firewall, which is also the default. I also configured the tailscale firewall according to the online teaching video, but the result is still invalid. Can you teach me how to configure the firewall under these circumstances? Thank you

After your configuration, it is possible to access openwrt and its internal network devices from the external network by default, which is the exit-node function of openwrt, which does not work on the client.


Updates branch and adds working example of NPE

This PR simply updates @Justinezgh branch, and adds a working notebook here

I'm using this model:
from sbids.models import ConditionalRealNVP, AffineSigmoidCoupling

bijector = partial(AffineSigmoidCoupling,
                   layers = [64,64],
                   n_components = 8,
                   activation = jnp.sin)

NF = partial(ConditionalRealNVP,
             n_layers = 4,
             bijector_fn = bijector)

class SmoothNPE:
    def __call__(self, y):
        net = lotka_volterra_y_bijector(y)
        net = jnp.sin(hk.Linear(256, name='comp1')(net))
        net = jnp.sin(hk.Linear(256, name='comp2')(net))
        net = jnp.sin(hk.Linear(256, name='comp3')(net))
        net = hk.Linear(8, name='comp4')(net)
        nvp = NF(4)(net)
        return tfd.TransformedDistribution(nvp,
                                           tfb.Chain([tfb.Invert(lotka_volterra_theta_bijector),
                                                      tfb.Scale(10.),
                                                      tfb.Shift(-0.5)]))

nvp_nd = hk.without_apply_rng(hk.transform(lambda theta,y : SmoothNPE()(y).log_prob(theta).squeeze()))

@Justinezgh note that I have added hard coded bijectors in the lotka-volterra module, which can be simply used to map the inputs and outputs to unconstrained more or less normal variables: lotka_volterra_theta_bijector,lotka_volterra_y_bijector
Feel free to update these bijectors if you have better ones ;-)

nop I used it and did this
lotka_volterra_y_bijector = tfb.Chain([
                 tfb.Scale(0.38),
                 tfb.Invert(tfb.Softplus()),
                 tfb.Scale(0.021)
                 ])

lotka_volterra_theta_bijector = tfb.Chain([
                 tfb.Scale(jnp.array([2.,2.,2.,2.])),
                 tfb.Shift(jnp.array([0.125,3,0.125,3])),
                 tfb.Log()
                 ])

transformation_params = tfb.Chain([tfb.Scale(1/20),tfb.Shift(10),lotka_volterra_theta_bijector])
transformation_x = tfb.Chain([tfb.Scale(1/30),tfb.Shift(16),lotka_volterra_y_bijector])


App launches, shows test RGB cube, loops connecting-disconnecting.

SteamVR Overlay shows up with menu and applications but keeps disconnecting-connecting-disconnecting loop.

hmmm, I've had it happen sometimes, but usually it resolves itself by closing out ALVR+SteamVR, closing the app on the headset, and then starting ALVR+SteamVR and then the app again. But tbh I'll keep this marked as a bug bc it's persistent enough to warrant a bit of extra care

oh also, because I just ran into this bug: hold the top button and the crown for a few seconds, and make sure there aren't any ghost instances of ALVRClient, sometimes the Xcode debugger doesn't clean up properly. And also make sure to use Medium (4288) or lower resolution, because I don't think the Vision Pro decoder can decode higher than that.

oh also, because I just ran into this bug: hold the top button and the crown for a few seconds, and make sure there aren't any ghost instances of ALVRClient, sometimes the Xcode debugger doesn't clean up properly. And also make sure to use Medium (4288) or lower resolution, because I don't think the Vision Pro decoder can decode higher than that.

I am new to this. Where do we set those settings?

oh also, because I just ran into this bug: hold the top button and the crown for a few seconds, and make sure there aren't any ghost instances of ALVRClient, sometimes the Xcode debugger doesn't clean up properly. And also make sure to use Medium (4288) or lower resolution, because I don't think the Vision Pro decoder can decode higher than that.

Oh wait! I see now. It's on the desktop client, not XCode. 😅

oh also, because I just ran into this bug: hold the top button and the crown for a few seconds, and make sure there aren't any ghost instances of ALVRClient, sometimes the Xcode debugger doesn't clean up properly. And also make sure to use Medium (4288) or lower resolution, because I don't think the Vision Pro decoder can decode higher than that.

Got it working!!! Thank you so much for all of your help!! Looking forward to future iterations!! :)


Anytime i try set CHANNEL_LAYERS i get this exception

Unhandled exception in thread started by <function check_errors..wrapper at 0x7f7ff45a7bf8>
Traceback (most recent call last):
File "/home/waqas/testing/lib/python3.4/site-packages/django/utils/autoreload.py", line 226, in wrapper
fn(*args, **kwargs)
File "/home/waqas/testing/lib/python3.4/site-packages/channels/management/commands/runserver.py", line 37, in inner_run
self.channel_layer = channel_layers[DEFAULT_CHANNEL_LAYER]
File "/home/waqas/testing/lib/python3.4/site-packages/channels/asgi.py", line 53, in getitem
self.backends[key] = self.make_backend(key)
File "/home/waqas/testing/lib/python3.4/site-packages/channels/asgi.py", line 48, in make_backend
routing=routing,
File "/home/waqas/testing/lib/python3.4/site-packages/channels/asgi.py", line 70, in init
self.router = Router(self.routing)
File "/home/waqas/testing/lib/python3.4/site-packages/channels/routing.py", line 27, in init
self.routing.extend(entry.expand_routes())
AttributeError: 'str' object has no attribute 'expand_routes'
I've tried both BACKENDS same error. here is how I am setting it
CHANNEL_LAYERS = {
"default": {
"BACKEND": "asgi_redis.RedisChannelLayer",
"ROUTING": "testproject.urls.channel_routing",
"CONFIG": {
"hosts": [("localhost", 6379)],
}
},
}

What does your channel_routing look like? The error seems to indicate you have a string in there rather than a route() - there should be a nicer error if so.

Yes, that is exactly the problem. I was using
"websocket.receive": consumers.ws_message,
insted of route("websocket.receive": consumers.ws_message,)

OK, I'll update the code to show a nicer error in that case.


feat: Set ArtifactHubPkg{}.install field

Description
Fill it with the OCI URL as we were doing so far. E.g:
The policy can be obtained using [`kwctl`](https://github.com/kubewarden/kwctl):
```console
kwctl pull ghcr.io/ocirepo/namespace/verify-image-signatures:v0.2.1
```

We forgot to fill this, looking at the RFC.
This will need a new release to be consumed by kwctl in 1.6.0-rc3
Test
Amended unit tests.
Additional Information
Tradeoff

Potential improvement

We could expand it with instructions to do a kwctl scaffold clusteradmissionpolicy or the like. I welcome suggestions.

Please, do not tag a new release. I'm about to do another release of this library with the context-aware code merged


GitHub: Invite member

Dear commiters, could you please invite me to CX members as a member of IDS&GDS teams (SDF/SDE/MSO)
Eclipse user<EMAIL_ADDRESS>GitHub User: @galyshann
Commiters:@almadigabor @FaGru3n
@ciprianherciu please verify that I am part of the team

I can confirm @galyshann is part of the team

Hi @tomaszbarwicki,  thank you, I was added to Catena-X (ng) organization.
Could you please add me also to Eclipse Tractus-X  for being able to create Projects for our products

Hi @galyshann also added you into our Eclipse Tractus-X project.

Please make sure, that you accept the invitation you receive from GitHub for Eclipse Tractus-X, after you have been added as project contributor.

If you can see the logo for the org under you personal profile should be successful.
Please review and close the issue afterwards.

Hi @FaGru3n thank you!
I can see the logo and created the Project, but still can`t Link it to our repositories. What should be done for that?

Your welcome...
Hmm did not get your point what you try to achive with linking a GitHub project and  an repository?
If you want to have more issues from the repo on your project then only some more issue could be assigned to the GitHub Project... so created a little demo issue for that in the repo itself.

Ah thanks for clarification... 😉  one point i also did not know thanks but guess some more permissions are needed to modify the projects within repositories. your current permission is the triage permission like described in contributor permissions
So for now, i linked the organisation project directly into your repository as repository project.

Please verify and close the issue, thanks in advance.

Exactly! Thank you, @FaGru3n!
May I ask you to do the same for
Project: SD-Factory link to Repo: https://github.com/eclipse-tractusx/sd-factory
and MSO:
Project: https://github.com/orgs/eclipse-tractusx/projects/63 and Repo: https://github.com/eclipse-tractusx/managed-service-orchestrator

Hi @galyshann also done.
Please review and close the issue afterwards.


minor fix

Hi @samay-rgb,
Good catch but I'll close the PR since useSsr is depreciated and will be removed soon.
Thanks


Fixing version compatibility

Hotfix for compatibility while not supporting sklearn 0.22

@dmvieira This looks good; would you mind pulling the latest changes from master before this is merged? Would like to get a working build on the books before formally approving.

did

Thanks! Merging now.


Support pre-1.14 versions of Go

Now that the es6 branch is merged into master, Go 1.14 or newer is needed to build goja.  From what I can tell, this is only due to the new dependency on the hash/maphash stdlib package that was added in 1.14.  Since I'm currently stuck in an environment using Go 1.13, I tried my hand at fixing this by adding a drop-in replacement github.com/dop251/goja/maphash package to allow building goja on older versions of Go.  Here's a link to my branch.
For anyone using 1.14 or newer, github.com/dop251/goja/maphash uses type aliases to use the stdlib hash/maphash implementation, otherwise for older versions of Go it uses an adapted version of this file.  The main change was to use math/rand.Uint64() and hash/crc64 instead of the builtin's runtime_fastrand/runtime_memhash functions.  I tried running the tests for both goja and goja_nodejs using both Go 1.13.14 and Go 1.14.7 with these changes in place and everything passed, but I haven't gone further than that yet.
I don't know if this is an acceptable change for you, but I figured it was worth a shot.  I don't know if you are planning to use other features that are only available in Go 1.14 or newer, or if maintaining a replacement package like this would be an unacceptable maintenance burden for you.  If it is acceptable, I'm happy to open a PR with my changes.

Why are you stuck with 1.13?

I'm developing at Go package that's being built within the OpenWRT project.  The build system of 19.07.2, the current stable release, uses Go 1.13 and this isn't something I have the ability to change.  You can imagine my disappointment when ES6 and the Node.js search algorithm got merged and I found out I can't build goja anymore because of this! :tired_face:

Well, I'm sorry to say that, but I'm not going to support old versions of Go. Due to the compatibility promise upgrading should be a trivial task, especially in almost 6 months time since 1.14 was released. I suggest you open a ticket with OpenWRT and in the meantime use your branch. 1.14 is going to be a legacy version soon anyway, as 1.15 has just been released.
Also, if you're not linking against native libraries you may want to consider cross-compilation in which case you don't even need OpenWRT build system at all.

I completely understand, and if I was in your place I'd likely make the same decision.  Thanks for the quick response.


Homer persistence enabled fails to create a pvc

Details
Helm chart name and version:
homer-7.1.0
Container name and tag:
b4bz/homer:21.09.2
I also tested b4bz/homer:latest (Latest Image was 20/03/2022)
What steps did you take and what happened:
The homer chart ignores persistence enabled: true and does not attempt to create a pvc.
I have used multiple helm charts by k8s-at-home and they all work fine and create a pvc.
Relevant Helm values:
persistence:
  config:
    enabled: true
    mountPath: /www/assets
    storageClass: freenas-nfs-csi
    accessMode: ReadWriteMany
    size: 1Gi

What did you expect to happen:
I expected a homer PVC to be created.
Anything else you would like to add:
I am running MicroK8s v1.23.4-2+98fc2022f3ad3e on Ubunutu 20.03 AMD64 in a 3 node cluster.
My NAS NFS target is TrueNAS Core 12.
I am using https://github.com/democratic-csi/democratic-csi provisioner for nfs
I also got the same result when using the nfs.csi.k8s.io provisioner v1.20
Additional Information:
After applying the helm chart when I query the cluster for a pvc there is no homer pvc.
You can see two succesful PVC claims for other deployments that are Bound.
One is using the freenas-nfs-csi strorage class.
$ kubectl get pvc --all-namespaces
NAMESPACE   NAME                       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
default     photoprism-config          Bound    pvc-04f8b44a-ee1f-437f-bcd0-b6ee796c9748   1Gi        RWX            freenas-nfs-csi     22h
default     data-wikijs-postgresql-0   Bound    pvc-638e8615-bb7f-4102-ae92-64814ca83cfc   10Gi       RWO            freenas-iscsi-csi   21h

Do you happen to have https://github.com/k8s-at-home/charts/blob/master/charts/stable/homer/values.yaml#L50enabled?
In that case the config persistence item would be overwritten by the configured configMap.
I'll add a note to the README about this behavior if that is indeed what is causing it for you.

Yes. I have configmap enabled.

Any chance we can get this issue resolved? Configmap is required. That is how the homer config is stored.

Hi @sudo-rm-rf-slash we're a very small team (2-3 people maintaining these charts) and it's unfortunate to say we don't prioritize applications we do not use ourselves. Any help would be great from you or the the community to help fix issues. I hope you understand.

@sudo-rm-rf-slash as a workaround, you can just change this:
persistence:
  config:
    enabled: true
    mountPath: /www/assets
    storageClass: freenas-nfs-csi
    accessMode: ReadWriteMany
    size: 1Gi

to
persistence:
  whatever:
    enabled: true
    mountPath: /www/assets
    storageClass: freenas-nfs-csi
    accessMode: ReadWriteMany
    size: 1Gi

and mount your PVC under a different name whatever so it doesn't clash with the configmap.
For what it's worth, looks like our setups are almost identical (MicroK8s, TrueNAS, Democratic CSI). For my Homer instance, instead of making such a lightweight app rely on persistent storage, I store my assets in a configmap and mount that into the pod as a directory.
Relevant part of my values.yaml:
# make a configmap under a different name and mount it as a dir
persistence:
  images:
    name: homer-images
    enabled: true
    mountPath: /www/assets/custom
    type: configMap

configmap:
  # configmap with images
  images:
    enabled: true
  # regular Homer config here
  config:
    # -- Store homer configuration as a ConfigMap
    enabled: true
    # -- Homer configuration. See [image documentation](https://github.com/bastienwirtz/homer/blob/main/docs/configuration.md) for more information.
    # @default -- See values.yaml
    data:

Then the images are stored with my values.yaml in a subdirectory called images and are loaded into the configmap at deploy time,  like this:
#!/bin/sh
helm upgrade -i --create-namespace -n homer homer -f values.yaml k8s-at-home/homer
kubectl create configmap -n homer homer-images --from-file=logos --dry-run -o yaml | kubectl apply -f -


[Flaky Test] Reenable two flaky test on Windows

Description
Fixes #15004
Fixes #13600
My environment: Windows 2016 Server with CUDA 10.0 + cuDNN 7.5 + MKLDNN
I could not reproduce the error using latest master(commit: 31438583d72dcd72bedb6e83a0884f53a9a8fe37)
test_l2_normalization
C:\incubator-mxnet\tests\python\unittest>nosetests --logging-level=DEBUG --verbose -s test_operator.py:test_l2_normalization
[INFO] Setting module np/mx/python random seeds, use MXNET_MODULE_SEED=683236958 to reproduce.
[WARNING] *** test-level seed set: all "@with_seed()" tests run deterministically ***
test_operator.test_l2_normalization ... [INFO] Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1163638589 to reproduce.
ok

----------------------------------------------------------------------
Ran 1 test in 2.281s

OK

I ran 10k times
[DEBUG] 9985 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=812676407 to reproduce.
[DEBUG] 9986 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2025796828 to reproduce.
[DEBUG] 9987 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2101832288 to reproduce.
[DEBUG] 9988 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=445269518 to reproduce.
[DEBUG] 9989 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=905315198 to reproduce.
[DEBUG] 9990 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=771148112 to reproduce.
[DEBUG] 9991 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=46635746 to reproduce.
[DEBUG] 9992 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1900954078 to reproduce.
[DEBUG] 9993 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1151837497 to reproduce.
[DEBUG] 9994 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=333260159 to reproduce.
[DEBUG] 9995 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=918969863 to reproduce.
[DEBUG] 9996 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=795988550 to reproduce.
[DEBUG] 9997 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=812630738 to reproduce.
[DEBUG] 9998 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=205564357 to reproduce.
[DEBUG] 9999 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1744386769 to reproduce.
[DEBUG] 10000 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=950060972 to reproduce.
ok

----------------------------------------------------------------------
Ran 1 test in 22706.649s

OK

test_softmin
1. C:\incubator-mxnet\tests\python\unittest>nosetests --logging-level=DEBUG --verbose -s test_operator.py:test_softmin
[INFO] Setting module np/mx/python random seeds, use MXNET_MODULE_SEED=114386306 to reproduce.
[WARNING] *** test-level seed set: all "@with_seed()" tests run deterministically ***
test_operator.test_softmin ... [INFO] Setting test np/mx/python random seeds, use MXNET_TEST_SEED=350762988 to reproduce.
[17:51:49] c:\incubator-mxnet\src\operator\../common/utils.h:450: MXNET_SAFE_ACCUMULATION=1 is recommended for softmax with float16 inputs. See https://mxnet.incubator.apache.org/versions/master/faq/env_var.html for more details.
ok

----------------------------------------------------------------------
Ran 1 test in 0.234s

OK

2. C:\incubator-mxnet\tests\python\unittest>nosetests --logging-level=DEBUG --verbose -s test_operator.py:test_softmin
[INFO] Setting module np/mx/python random seeds, use MXNET_MODULE_SEED=855097121 to reproduce.
[WARNING] *** test-level seed set: all "@with_seed()" tests run deterministically ***
test_operator.test_softmin ... [INFO] Setting test np/mx/python random seeds, use MXNET_TEST_SEED=872415515 to reproduce.
[17:53:50] c:\incubator-mxnet\src\operator\../common/utils.h:450: MXNET_SAFE_ACCUMULATION=1 is recommended for softmax with float16 inputs. See https://mxnet.incubator.apache.org/versions/master/faq/env_var.html for more details.
ok

----------------------------------------------------------------------
Ran 1 test in 0.281s

OK

3.
C:\incubator-mxnet\tests\python\unittest>nosetests --logging-level=DEBUG --verbose -s test_operator.py:test_softmin
[INFO] Setting module np/mx/python random seeds, use MXNET_MODULE_SEED=1589347991 to reproduce.
[WARNING] *** test-level seed set: all "@with_seed()" tests run deterministically ***
test_operator.test_softmin ... [INFO] Setting test np/mx/python random seeds, use MXNET_TEST_SEED=644753921 to reproduce.
[17:54:53] c:\incubator-mxnet\src\operator\../common/utils.h:450: MXNET_SAFE_ACCUMULATION=1 is recommended for softmax with float16 inputs. See https://mxnet.incubator.apache.org/versions/master/faq/env_var.html for more details.
ok

----------------------------------------------------------------------
Ran 1 test in 0.172s

OK

and I ran 10k times
[DEBUG] 9984 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=599685539 to reproduce.
[DEBUG] 9985 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1665226214 to reproduce.
[DEBUG] 9986 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1114501375 to reproduce.
[DEBUG] 9987 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1971865213 to reproduce.
[DEBUG] 9988 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=950058536 to reproduce.
[DEBUG] 9989 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=924354158 to reproduce.
[DEBUG] 9990 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1184172882 to reproduce.
[DEBUG] 9991 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=101999963 to reproduce.
[DEBUG] 9992 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1243690743 to reproduce.
[DEBUG] 9993 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1696032781 to reproduce.
[DEBUG] 9994 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1869141094 to reproduce.
[DEBUG] 9995 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=353658520 to reproduce.
[DEBUG] 9996 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=353012484 to reproduce.
[DEBUG] 9997 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=765072115 to reproduce.
[DEBUG] 9998 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1216702949 to reproduce.
[DEBUG] 9999 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=678578924 to reproduce.
[DEBUG] 10000 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=169040545 to reproduce.
ok

----------------------------------------------------------------------
Ran 1 test in 1491.462s

OK

Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes
Ping @perdasilva @marcoabreu for review
Comments

@mxnet-label-bot add [Test, Windows, pr-awaiting-review]


deleted itsdangerous from requirements as no needed

closes|addresses https://github.com/cmu-delphi/delphi-epidata/issues/848
Summary:
Actually, Flask version is 2.2.2, just deleted itsdangerous from requirements as not needed
Prerequisites:

[ ] Unless it is a documentation hotfix it should be merged against the dev branch
[ ] Branch is up-to-date with the branch to be merged with, i.e. dev
[ ] Build is successful
[ ] Code is cleaned up and formatted

@dshemetov @melange396 looks like the Flask 2.2 upgrade was merged in #1043 and released in v0.4.4 back in December; was that intentional?

Huh, definitely not. That PR actually just sorted the dependencies, but didn't upgrade. Here is the commit that upgraded us back in September 2022.

that's substantially less suspicious as it was part of the initial 0.4.0 release, but still feels odd not to have marked it at the time

Yea, well, either it was intentional and undocumented or unintentional and lucky. Either way, looks like we've been on Flask 2.2 since September without visible issues 🍀🚀


Update repositories.txt

I really don't understand @ArduinoBot.
I changed the tag from 1.0, to 1.0.0 to create a new tag for you to look at in the file, and released it. But I find it ridiculous If I have to release this with something other than 1.0 or similar just because you use tags and don't refresh them if I re-release to get a bot to behave

THAT ISN"T MY LIBRARY! Can I please get a human to review this?

sorry, I didn't realize I was not on my own request. SORRY!!


CLOUDSTACK-9989: Extend smoketests suite

Adding few areas of tests to the smoketests since they are not covered when doing PR testing but important at the same time.

@borisstoyanov can you confirm if these tests run okay with Trillian? I've had moved some component tests to run part of Travis that you may consider to include as well, however keep in mind some tests run longer than half a day, while a typical Trillian smoke tests may take about half a day or less.

Yes @rhtyd, I've run them on a Trillian env before moving them in the smoketests

ping @DaanHoogland @nvazquez @PaulAngus for review

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

@borisstoyanov as part of moving these tests, maybe we can include them in .travis.yml too?

Packaging result: ✖centos6 ✔centos7 ✔debian. JID-1271

Thanks @rhtyd, I've pushed the change in travis yml file.

okay @borisstoyanov  we might need to refactor/rearrange them at some point, I'll fire some tests.
@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian.


Re-generate the crds by using line breaking

Changes
This is a fix PR for the PR: https://github.com/shipwright-io/build/pull/667
I also asked Matt and Zoe to verify, they also generate normally WITH line-breaking, but I tried several ways, all didn't work..... Finally, I gave up, I don't know why there is no line-breaking when I ran the make generate-crds in my local Mac.
Maybe because my Mac is more powerful than other ones. :(
Below is what I tried:

Ask Matt and Zoe help, they can generate with line-breaking normally on the Mac
I tried on Ubuntu, can also generate with line-breaking
Then I tried to upgrade my Golang to 1.15, upgrade/downgrade, my controller-gen, change GOPATH, etc... they all didn't work

Because it is ONLY my Mac problem, so I provide this PR to change to the NORMAL format with line-breaking in this PR.
And I will follow the issue https://github.com/kubernetes-sigs/controller-tools/issues/514#issuecomment-800837188 to see how to solve in future.
Thanks!
/kind misc
Submitter Checklist

[ n ] Includes tests if functionality changed/was added
[ n ] Includes docs if changes are user-facing
[ y ] Set a kind label on this PR
[ n ] Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes
None

/kind misc

/kind cleanup

Thanks, I would like to see what @HeavyWombat thinks on this issue, before approving. PR looks good to me.


feat(scorecard): add psa labels for scorecard namespace

Welcome to Cryostat! 👋
Before contributing, make sure you have:

[x] Read the contributing guidelines
[x] Linked a relevant issue which this PR resolves
[x] Linked any other relevant issues, PR's, or documentation, if any
[x] Resolved all conflicts, if any
[x] Rebased your branch PR on top of the latest upstream main branch
[x] Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
[x] Signed all commits: git commit -S -m "YOUR_COMMIT_MESSAGE"

Related to https://github.com/cryostatio/cryostat-operator/pull/450
Description of the change:
Label namespace with restricted standard (warn and audit only).
Motivation for the change:
Ensure scorecard and bundle pods can be run under restricted policy.

I could not use enforce restricted mode due to:
INFO[0008] Creating a File-Based Catalog of the bundle "quay.io/cryostat/cryostat-operator-bundle:2.4.0-dev"
INFO[0009] Generated a valid File-Based Catalog
FATA[0009] Failed to run bundle: create catalog: error creating registry pod: error creating pod: pods "quay-io-cryostat-cryostat-operator-bundle-2-4-0-dev" is forbidden: violates PodSecurity "restricted:latest": runAsNonRoot != true (pod or container "registry-grpc" must set securityContext.runAsNonRoot=true)

Issue: https://github.com/operator-framework/operator-sdk/issues/5939


modal uses large memory when running in nwjs

I show a Semantic modal in nwjs, and change a text in this modal every second. The memory usage is increasing fast from 50MB to 600MB. However  if I change a text in other div except modal, the memory usage will not increase.
Is it a bug? What is a right way to change text in Semantic modal?

Closing until there's a test case.


Add ADR for e2e tests moving to their own repo

What
Created an ADR discussing separating the e2e tests from forms-deploy and moving them into a new repo called forms-e2e-tests
How to review

Semantic: Do you agree with the changes?
Syntactic: Spelling, grammar, etc.

Who can review
Anyone who's interested in the e2e tests!

Presumably this will require some changes to our deploy pipelines, to get the end to end test code along with the app code and the terraform. I don't think this would cause issues though? 🤔


Task options vs action options

I've got some best practice questions that I'd like to clarify, starting from this one: what is the difference between
task: expand=True
run: ...

and
task:
run: expand = True

and which one is preferred?

And the same goes for workdir under task vs under action level.

I do not think we have expand option for task (see a list here)
workdir can be nested so
task: workdir='..':
run: workdir='..'

will run at ../.. but you can use absolute paths. Both options exist because a task can contain multiple actions and regular python statements.
env for actions were added recently. The logic is the same (env at the task never can be overridden by env at the action level).
I would generally recommend the use of action level options because it would be easier to add/remove task to debug the code locally and change it to task. In this sense, perhaps we should remove these task options.

I do not think we have expand option for task

Good to know ... then that page needs an update, if you search for expand=True you'll see some of them are in task.

workdir can be nested

A behavior that makes good sense to me and I can imagine it be useful sometimes; but might be confusing to less experienced people.

I would generally recommend the use of action level options because it would be easier to add/remove task to debug the code locally and change it to task

Yes I think we should remove task options that are equivalent.

https://vatlab.github.io/sos-docs/doc/documentation/Remote_Execution.html is fixed. Thank you for reporting the problem.


Add: ABC News

Channel Name
ABC News
Alternative Names (optional)
No response
Network (optional)
ABC
Owners (optional)
Australian Broadcasting Corporation
Country
AU
Subdivision (optional)
No response
City (optional)
Sydney
Broadcast Area
c/AU
Languages
eng
Categories (optional)
news
NSFW
FALSE
Launched (optional)
1947-06-01
Closed (optional)
No response
Replaced By (optional)
No response
Website (optional)
https://www.abc.net.au/news/
Logo
https://upload.wikimedia.org/wikipedia/en/thumb/d/df/ABC_News_Channel.svg/375px-ABC_News_Channel.svg.png
Notes
No response

https://iptv-org.github.io/channel?id=ABCNewsAustralia.au


Issues pane: Sort issues in milestone by issue priority

I'd like the issue pane to sort my milestone issues by priority, so that they appear in the same order as on GitHub.
GitHub:

Extension:

Happy to take a crack at it myself, might just need some direction.

You can define your own queries as well as modify the "My Issues" query in settings.json, using the same query syntax as on github.com (see https://docs.github.com/en/github/searching-for-information-on-github/understanding-the-search-syntax).  You can do this for both Pull Requests and Issues.
    "githubIssues.queries": [
        {
            "label": "My Issues",
            "query": "is:issue is:open repo:${owner}/${repository} sort:comments-desc "
        },
        {
            "label": "Created Issues",
            "query": "author:${user} state:open repo:${owner}/${repository} sort:updated-desc"
        },
        {
            "label": "Closed Issues",
            "query": "author:${user} state:closed repo:${owner}/${repository} sort:updated-desc"
        }
   ]

Does this help?

I don't think so, because (unless I'm mistaken) the settings syntax isn't expressive enough to recreate the default behaviour of grouping tickets by milestone. I also don't think GitHub query syntax offers sorting by milestone priority.
I was assuming that milestone grouping was probably implementing in the extension itself, and that ordering by milestone priority (assuming the data is even available via the GitHub API) would need to go in the same place.

I think you are looking for a way to group issues. If we provide a way to group them, then you can use GitHub's search syntax to sort however you want.

Duplicate of https://github.com/microsoft/vscode-pull-request-github/issues/1881

Sounds good! I do still think the default query should sort by milestone priority, if possible, but if I can eventually do it myself that's good too.


[WIP] Add a mesh input that exposes its surface

Currently crashes as get_surface_count and surface_get_arrays isn't properly exposed on Mesh. Probably requires a PR upstream.

This is starting to work,
Needs: https://github.com/godotengine/godot/pull/21481

I'm merging this as the core of this now works, just need to work the example out further but can't until I fix a few other bugs :)


power_of_2_(Bit_Manipulation).py

Description
Please include a summary of the change and which issue is fixed. List any dependencies that are required for this change.
Fixes #761
Replace issue_no with the issue number which is fixed in this PR
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update
[x] Documentation Update

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

@kamleshjoshi8102 add test case

@kamleshjoshi8102 add test case

Added Sir!


Fix check branches for Bears for passing-passing case

Since the structure of the commits for passing-passing case changed, the check branches for this type of build pair was failing. This PR fixes that.

Pull Request Test Coverage Report for Build 2017

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

Totals

Change from base Build 1997:
0.0%

Covered Lines:
2890

Relevant Lines:
5310

💛  - Coveralls


feat: disable/enable sign in buttton

DCMAW-8928: iOS | Disable and add loading icon to Sign In button
Previously the "Sign in" button on the intro screen was not disabled when interacted with and could produce incorrect behaviour if the user interacted with the button again while the authentication modal was launching.
This PR implements disabling the button and reenabling it when the authentication modal is dismissed.
Checklist
Before raising your pull request:

[x] Commit messages that conform to conventional commit messages
[x] Ran the app locally ensuring it builds
[x] Ran the tests locally ensuring they pass on Build
[x] Pull request has a clear title with a short description about the feature or update
[x] Created a draft pull request if it is not yet ready for review

Before your pull request can be reviewed:

[x] Met all of the acceptance criteria specified in the user story on Jira

[x] Reviewed your own code to ensure you are following the style guidelines

[x] Ran the app and tested the feature on a range of device sizes
Please include iPod Touch, iPhone SE and iPhone 11 as a minimum.

[x] Written Unit and Integration tests if needed

[x] Met all accessibility requirements?

[x] Checked dynamic type sizes are applied
[x] Checked VoiceOver can navigate your new code
[x] Checked a user can navigate only using a keyboard around your new code

Before merging your pull request:

[x] Ensure that the code coverage and SonarCloud checks have passed
[ ] Actioned and resolved all comments, reaching out to reviewers for clarifications if necessary.
[x] Ran the app to ensure that no regressions have been caused by changes during code review.

@jdubey @mcgarj
Going to leave some comments on the implementation here as it's a bit strange


LUIS-Samples app build-app-programmatically-csv syntax issue.

Issue Description
I am looking at this project from LUIS-samples
https://github.com/Microsoft/LUIS-Samples/tree/master/examples/build-app-programmatically-csv
Code Example
When I run it I get following error.

Index.js is importing following files
const parse = require('./_parse');
const createApp = require('./_create');
const addEntities = require('./_entities');
const addIntents = require('./_intents');
const upload = require('./_upload');
and it I comment the line where parse.js is imported. Then same error occurs on next file which is _create. and so on.
I check the syntax of all the files and it it correct.

@rjgmail88, can you please file LUIS-Samples related issues in the LUIS-Samples repository?
@v-geberr or @DeniseMak, can you assist @rjgmail88? Thanks!
Closing issue.

Hi stevengum97, I was not able to create one there. I don't see New issue option. Can you reopen it and somehow map it to LUIS ?

Since an issue was created and you, Dina and I responded there, I'm going to leave this closed :)


Sqlite ReadOnlyException (sqlite code 1032)

DBFlow Version:
3.0.0
Bug or Feature Request:
Description:
copy database file , from assets to  app's databases folder. then app open it , read data its ok, when open transaction , like this :
ITransaction xx = FastStoreModelTransaction.updateBuilder(xxModel); FlowManager.getDatabase(aa.class).executeTransaction(xx);
throw exception .
Have anyone come across ????

seems like a question and not a bug from DBFlow. This should be posted on stackoverflow.com


Support for no_std environments

I know this isn't a priority, but I thought I'd get the issue down in writing for tracking purposes.
Summary
Problem
The crate is currently incompatible with no_std
Impact
The crate can't be used in embedded or bare-metal environments, like on a Raspberry Pi or ESP32.
Solution
I haven't done a comprehensive survey of what would be required to make rs-ucan compatible with no_std, but at minimum we must:

use default-features = false for serde, and explicitly list derive as a feature
Support using serde-json-core instead of serde_json
Support using heapless in place of dynamically allocated types like Vec and String

There's likely more work that would be required than the above, especially to support both environments without a ton of duplicated code, but the above points would be good starting points for anyone investigating this!

This sounds like a great thing to have :+1:


[da] Wrong article before numbers larger than and including one million

When I see the numbers spelled out in Danish at https://numbertext.github.io/ all numbers from 100 and up have the article "et" in front of them.
This is wrong. In Danish, the numbers 100 and 1,000 do in fact take the article "et", but all numbers from one million and up take the article "en".
For example:
1,000,000 = en million
1,000,000,000 = en milliard
1,000,000,000 = en billion
etc.

Fixed in commit 44a07ff9370dd8520ae7de2c400a7de10d70c4af, thanks for your bug report!

Also fixed in the web demo.


[MeshModel] [UX]: Icon for Kubernetes Component - Authorization Policy

Current Behavior
Meshery is a powerful platform that contains over 200 integrations for managing cloud-native applications. MeshMap is an extension of Meshery that visually represents these integrations and components. Currently, most of the icons used in MeshMap have the default shape of a circle. However, to improve visual clarity and consistency, we need to design custom icons for MeshMap components.
Desired Behavior
A new Icon for  Authorization Policy needs to be created. This issue calls for a volunteer to draft a new Icon.
Instructions for Components
While the default shape for new components is a circle, each component should be considered for its best-fit shape.

Review and familiarize with the available set of predefined relationship types. Refer to the Cytoscape node types for a list of possible shapes.
Propose a specific shape, best-suited to visually represent the Component. Example - Deployment as a pentagon, DaemonSet as a skull icon, etc.
Create two versions of the icon one is white and another one is colored
Make a PR after adding the icon inside the new-icon folder present in the meshery repository
Provide the icon in SVG format

Contributor Guides and Handbook

MeshModel Repository
🖥 MeshModel Overview
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

/assign @Ayush9026 i will fix this.

Hey Meshers, I noticed this task/issue was marked stale in 2023 and closed due to inactivity, then reopened recently. Does this still need resolution? If so, may you please assign this task to me? Thx!


Update Composer dependencies (2021-11-25-00-05)

Visual regression test passed!
View the visual regression test report


erasing filters and adding warning instead #65

https://github.com/sociomantic-tsunami/nessie/issues/65

@conor-cafferkey-sociomantic corrected.


Make setUp/tearDown test methods public

Coverage remained the same at 66.938% when pulling 4c63d39b6272b3f076ac029ee8b513393fd6b7fe on CyberiaResurrection:master into d2a3cb7397c2f2643753f622bad4e1ab6a79ed29 on Algo-Web:master.