Is "If a back-end API doesn't require a scope (not recommended), you can use clientId as the scope in the calls to acquire tokens." still correct?

Just saw a test case telling that the sentence is outdated (816128)
Should we remove this sentence

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

ID: 4c6d2219-cb28-5527-1079-6e3195cad282
Version Independent ID: 70c2aad0-6883-51a9-fed7-01be62302483
Content: Azure AD v2.0 JavaScript single-page application (SPA) guided setup - Microsoft identity platform
Content Source: articles/active-directory/develop/tutorial-v2-javascript-spa.md
Service: active-directory
Sub-service: develop
GitHub Login: @navyasric
Microsoft Alias: nacanuma

@negoe @SaeedAkhter-MSFT

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

@jmprieur My understanding is that this is a backend API with the same client ID as the SPA app. Is the recommendation to always register backend API as a separate client ID and add scopes?
@hamiltonha do you have any updated guidance on this?

#reassign:jmprieur per 4/24 doc sync

It seems the screenshots for the sample needs to be updated to reflect the current UI :/ @mmacy.

@jmprieur @navyasric @hamiltonha We've been recently informed that the best practice is to always have a separate registration API and SPA (except some cases) and we've been revising our samples accordingly (cc @kalyankrishna1 ). So I think we should remove this sentence now.

thanks @derisen. yes, let's do that.


Is/verification key construction

Implemented verification key computation
https://github.com/AztecProtocol/aztec2-internal/issues/1818

This became #68.


Fixed build-watch task

This fixes the build-watch task with the upgraded gulp.  Without this change you get:
Error: watching Specs//*.js,!Specs/SpecList.js,Source/Shaders//*.glsl: watch task has to be a function (optionally generated by using gulp.parallel or gulp.series)

Thanks for the pull request @jasonbeverage!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Thanks @jasonbeverage


Raspbian OS support

Description
On Raspbian (Debian port for Raspberry PI) a non-existent apt source was used, preventing this cookbook to be used on Raspberry PI with Raspbian
Issues Resolved
#109 Non-existent apt source configured on Raspbian
Check List

[ ] All tests pass. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/TESTING.MD
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable
[ ] All commits have been signed for the Developer Certificate of Origin. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/CONTRIBUTING.MD

As I mentioned in the related issue we don't take on platform support that we cannot continue to maintain through test boxes so I'll be closing this now.


Lighting regression

532aa53c6711e25cd513b21c0aff43b858f6a771 brings back the 2D/CV lighting issue that was fixed in #2515.  The commit before it, f507210c3af52a9a3ca17597e0731c4916964591, does not have the issue.  You can see this easily enough in the GeoJSON Sandcastle example.
I'm marking this a showstopper so that we at least look at it before 1.9.

Unfortunately this isn't going to make 1.9, but I'm leaving it as a showstopper so that we don't let it languish and try and fix it for 1.10.

Turns out this is OIT only now, since disabling fixes the issue.  It also works on IE (I'm not sure if IE has extensions needed for OIT or not)

Will look at post 1.10.

Recently came up again on the forum

Are there updated steps to reproduce this?  The code sample from #1825 doesn't produce the results shown in the screenshot for me.

@emackey just run the GeoJSON Sandcastle example linked to in the description and switch to 2D.

@bagnell thoughts on this? Is this an easy fix for 1.11?


Cleanup of shoot leftover resources

How to categorize this issue?
/area control-plane-migration
/kind enhancement
What would you like to be added:
We should introduce a cleanup mechanism for leftover resources in a Seed cluster that once contained the control plane of a Shoot cluster that are no longer needed since the Shoot cluster has been meanwhile force restored to a different seed (see #5123), or force deleted. Such resources include the shoot namespace (and all resources in it), the shoot BackupEntry resource, and the Cluster resource.
Why is this needed:
Without such a mechanism, leftover resources would remain in the seed cluster indefinitely and consume CPU and memory resources until manually removed.

Basically what we need is a controller that implements cleanup logic similar to the following script: https://github.com/plkokanov/control-plane-cleanup/blob/master/migrate-resources.sh. We should clarify what resource such a controller reconciles and uses in order to report the progress and errors of a cleanup operation.
It should be noted that the original Shoot resource can't be used for this purpose, as it's either already scheduled on a different seed (and is therefore reconciled by its gardenlet), or doesn't exist at all. For example, one could easily imagine a situation in which the Shoot has been force restored to a different seed and then deleted, before the controller responsible for deleting the leftover resources had the chance to do its job.
The possible alternatives are:

No resource. The controller detects the need for cleanup by detecting the leftover resources in the seed directly, e.g. a Cluster or a namespace resource in a seed that the corresponding Shoot is no longer scheduled on (or does not even exist). It does not report progress and errors in a status, only via log messages and events associated with the existing resources. The main disadvantages of this approach are:

Progress and errors are not reported in a status, and therefore harder to track and monitor, or even be aware that a cleanup is happening (and possibly failing) somewhere.
The detection logic is relatively complex especially if it involves each one of the 3 resources mentioned as opposed to e.g. only the namespace or the Cluster resource.

A "special" Shoot resource with a name different from the original one (as that one may still exist), created by copying the original one (including its status) and marking it as "leftover" somehow (via a label, annotation, or a new field). The main disadvantages of this approach are:

It has the potential of creating a lot of confusion between "normal" shoots and "leftover" shoots for the user. Special care should be taken that "leftover" shoots are distinguished from "normal" ones in the dashboard, kubectl queries, etc.
Implementation could be easier on one side, since "cleanup" could be implemented as a new Shoot operation. On the other side, the relatively heavyweight machinery used in the shoot controller (Botanist etc.) would most likely require adaptation to be applied to this special case, so all other operations would also be affected by the change. Many of the steps to properly initialize this machinery would not be really needed, however they would still be executed (and so may fail).
In addition it should be ensured that "leftover" shoots are never reconciled by the "normal" shoot controller, with any bugs or omissions having rather disastrous effect on existing shoots.
Purely conceptually, it overloads the existing Shoot resource with new semantics that could be more properly captured  by introducing a new resource kind.

A new resource kind created especially for this purpose that contains only the relevant details for performing the cleanup operation, e.g. ShootLeftover. While this approach avoids the disadvantages of the other two, it comes at the price of introducing a new resource (albeit a relatively simple one), together with its boilerplate API server code and maintenance cost associated with graduating to new versions, etc.

From the above approaches, I personally tend to favor the 3rd one (new resource kind). I consider it the most straightforward of the three, as it can be designed and implemented independently of the shoot controller by focusing only on the details relevant for implementing the cleanup properly, without affecting any existing implementation or logic. It is also the most flexible one, as it does not depend on any of the leftover resources actually being there. Even if the Shoot is long gone and its Cluster resource as well (so basically its impossible to recover the original Shoot), it would still be possible to create (and then delete) a ShootLeftover to get rid of e.g. an almost empty shoot namespace, while properly reporting any progress and errors in the resource status.
I already started exploring this approach in #5150.
Please share your feedback / thoughts on this topic.
/cc @timebertt @plkokanov @rfranzke @timuthy

Gut feeling would have been rather option #1 (no additional resource in the garden cluster). This feels, at least to me, more "encapsulated" (this topic concerns only the seed, so the seed should care and only the seed). The (old) seed cluster's job is to get rid of "stuff" that doesn't belong there. That's it's job, whether it's a deleted or migrated shoot. It contains "stuff", but the shoot is gone or this seed/gardenlet is not responsible anymore? OK, off that "stuff" goes to /dev/null. If that fails, which can happen also for regular cluster deletion, we raise an alert. We have other critical incidents where we raise alerts, e.g. failed backups. I know, that's not great because there is alert fatigue, but the line of argument is rather: 1.) we don't report all things that can go wrong back to the garden cluster either and 2.) even if there is an additional resource, nobody will check probably and both, these resources as well as alerts can be checked. But the main reason is, gut feeling, that we might want to contain/limit the issue to the seed that should be able to drive the subject matter autonomously, thereby reducing hopefully complexity (or not adding more). WDYT?

@vlerenc To your points: Even if we agree that "the topic concerns only the seed", it doesn't help with the above drawbacks. It will be hard to get visibility that something is happening or needs to happen, and what's the progress and any errors, and firing alerts for errors during cleanup seems a bit too much to me. With an additional resource, you can do e.g. k get slo -A and immediately see if there is anything that requires attention (ShootLevtover resources are short-lived, they are usually immediately deleted after creation so that the cleanup process could be executed, and after it's finished they are gone). You can then optionally build upon this more visibility if required (dashboard pages, grafana dashboards, etc.).

Thanks for the summary and pointing out the drawbacks 👍🏻 Reading all this, I tend towards option 3 as well, even though I initially had some mixed feelings about this ShootLeftover resource. Though, I don't have a better proposal at hand. Relying on the Cluster in the seed is a great idea, but the operation's status would indeed be intransparent and I never was a fan of only relying on alerts (given that there are so many false positives).

even if there is an additional resource, nobody will check probably

Let's rather fix this then. We have a similar behaviour already today with BackupEntrys. They can remain after Shoot deletion for some time, and if something goes wrong then it is reported in the status. Operators should check or it should at least become easier to get information about such problems (Dashboard/gardenctl commands). With a ShootLeftover resource it would be quite similar.

Hmm... I cannot agree with either of you, but that's OK.
Let me just add the following general thoughts:

I am not arguing for alerts as solution, just as mitigation that is cheaper than an extra resource.
I am generally not of the opinion we should create "planned work" for operators. That's just like "planned downtime". It should not be the case.
We should strive for automation and instead of investing into the transport of the information why something failed in cleanup, invest in said cleanup.
We should all try to keep complexity low. Encapsulation, low coupling and high cohesion are the usual means to that goal. So, if some component has the job to do something, then it should do that autonomously. Only if the above/remote component needs to know, it shall share that information, but otherwise it shall not.

Having said that, that's my "engineering feeling/response" to that question and others may have other opinions. It's what I would have done: "keep the problem local to the seed where it belongs to", but I am not the one doing it, so I can understand if you reject that viewpoint.

@vlerenc I personally do subscribe to every of the general statements above, it's just that I am not sure how exactly to implement the first approach while avoiding the issues that I mentioned.
Let me just point out that the existence of the extra resource doesn't mean that it has to be created manually in order for something to happen. For the "bad case" scenario, as part of the "fallback" the corresponding resource will be created (and immediately deleted to trigger the cleanup) automatically. And if it succeeds, everything will be cleaned up without the operator having to do anything it or even be aware that something is happening.
However, errors are possible and even likely (the migration failed and a force restore took place after all). I am currently testing the implementation and I am afraid that there are too many reasons why it could fail. From my perspective, making sure the errors are reported properly and made visible is a must. These errors are however not critical and therefore alerts would not be an appropriate approach.

@stoyanr If you want, we can talk out-of-band. Maybe I didn't get the problem entirely. It's about "controller detects the need for cleanup by detecting the leftover resources in the seed directly", so all happens in the seed, but the decision depends on the "tracking information" in the garden cluster. You listed:

Progress and errors are not reported in a status, and therefore harder to track and monitor, or even be aware that a cleanup is happening (and possibly failing) somewhere.

That is true and I have nothing to offer here. I accepted that as downside to keep complexity low.
I also cannot imagine that this is the only "progress and error information" that we then would not transport. There must be also other things we do not transport. Usually, one would try to solve that with resilient implementations that do not forget and retry.

I am currently testing the implementation and I am afraid that there are too many reasons why it could fail

Uh, that's where I became unsure after reading your reply.
Which problems and failures to cleanup are we talking about?
Isn't that primarily/exclusively about cluster resources?
If not, then I may be on the wrong track here.

The detection logic is relatively complex especially if it involves each one of the 3 resources mentioned as opposed to e.g. only the namespace or the Cluster resource.

Why is that the case? Naively, I thought the gardenlet sees the cluster resource, but no shoot resource for that seed (because it was either deleted or migrated, which is probably the same because of the effects of the SeedAuthoriser that probably needs to be adapted for proposal (3), but not here) and then takes action. Deletes stuff and only when done, the cluster can go. Shouldn't that be rather less instead of more effort than additional resources?
Look, I do not want to propose more effort. I wanted to propose less effort. If I am wrong, then ignore my suggestion.
I was just of the opinion that as long as we do not lose sight of the cluster residue, e.g. because of the cluster resource that you mentioned in the description of (1) and an alert (that will be ignored of course, like additional resources in the garden cluster in my opinion, unless we find a way to aggregate and dispatch them to the alert owners, which I am trying to discuss with Istvan anyway) that this would be simpler/easier/less complex.

Let me just point out that the existence of the extra resource doesn't mean that it has to be created manually in order for something to happen.

Yes, sure, that was understood.

@vlerenc Let's talk out-of-band. Just a few more comments:

Usually, one would try to solve that with resilient implementations that do not forget and retry. ... Which problems and failures to cleanup are we talking about?

It will be just such an implementation. However, "resilient" doesn't mean "always expected to eventually succeed, no matter what the current shoot state may be". I will write more about when it should be expected to succeed, as this needs to be specified / clarified independent of the current discussion.

Why is that the case?  ...

What you described is just one possible scenario. You may want to consider other cases, e.g. just a leftover backup entry, or just a cluster, or just a namespace without anything else. Some of these cases are not "normal" (they can only be achieved via manual actions or bugs in our components), and still the cleanup controller may be able to help for some of them.
Also consider that we should perhaps introduce a "grace period" after a fallback before the leftovers in the source seed are actually deleted, since without it they will be gone before the source seed has the chance to create the so-called "final full snapshot" (this is not critical, as the forced restoration will proceed without it after a timeout anyway, but this way it's slower and may result in data loss). This would be trivial to introduce with a resource (the controller will compare the resource deletion timestamp against the grace period to determine when to take action), and I am not even sure how to do it properly without a resource.

/assign
/assign @plkokanov

I would like to document my assumptions of when the new controller (independently if there is a new resource or not) should be expected to successfully cleanup the shoot leftover resources.
The controller should always be able to successfully cleanup the shoot leftover resources if the following conditions are met:

The seed cluster is healthy, i.e. its gardenlet, etcd-druid, and all needed extensions are installed an operational.
The shoot is in a state that can normally be reached by executing one of the available operations (creation, reconciliation, migration, restoration, and deletion). It can be failing in the middle of an operation, so "half-created", "half-migrated", etc. shoots should also be supported.

Conversely, the controller should not be expected to always be able to successfully cleanup shoot leftover resources (it might still work, but success is not guaranteed and hard to predict) if:

The seed cluster is not healthy.
The shoot is in a state that can't normally be reached by executing one of the available operations (either the shoot control plane was manually tampered with, or a bug in one of these operations led to the shoot being in a state that is not "normal").

In addition, under the above conditions, the controller should support shoots in different allowed states and feature gates, such as:

Awake as well as hibernated shoots.
Shoots created with UseDNSRecords enabled as well as disabled (the actual cleanup implementation should not itself depend on this feature gate).

I still strongly prefer the first approach mentioned above: only rely on the Cluster resource for detection and don't report into the garden cluster.
This is because:

We agreed that the cleanup mechanism should be a "best effort" mechanism that can help operators in cases we can foresee (currently that's only the forceful migration), but not in all cases. So let's not discuss cleanup of states that we cannot predict, especially ones caused by bugs. If we go down that road, we will never be finished, as we can never predict (and don't want to?) all possible bug scenarios.
Focusing on cleanup after forceful migration: In this case, we definitely got aware about a problematic situation on the old seed, as we migrated shoots away from it. Hence, I don't think that reporting into the garden cluster is actually necessary (or a strong argument), because operators will have to look into the broken seed anyway and there will still be things to cleanup manually. Listing Clusters or Namespaces labelled with a cleanup label (added after detecting and triggering the mechanism) is just as simple as listing another resource in the garden cluster.
If something goes south and leftovers remain on the seed and block the cleanup, there will be logs and events (or even a status on the Cluster resource if you want). So it will be easy to check why they are orphaned. No need to report such errors into the garden.
We consider the probably that such a cleanup is needed (e.g. forceful migration) to be quite low (at least currently). When looking at the complexity/effort/perfection of the solution (new resource, granular reporting, etc.), it simply feels like a huge overkill for the low probability and the nature of a "best effort cleanup". Comparing it to the effort of running a script against all orphaned namespaces on one seed, it just doesn't seem to be worth it.
Triggering the cleanup by detecting orphaned Namespace/Cluster resources will work (almost) always. Even if there is no controller creating the leftover resource. By definition, such orphaned resources already represent the "leftover state". So no need to declare it again somewhere else (which could in turn be inconsistent again).
That's also how kube controllers work. If there is a leftover resources created by the controller on behalft of an object that is gone now, they simply clean it up. Or the garbage collector kicks in. But this will be done somewhat silently without an extra resource to report to (at most some events), even though there are also quite some things that could go wrong.

However, if we learn that this mechanism is not enough and there is need for a fully-fledged cleanup mechanism with reporting to garden, etc. we can still introduce such a resource later on.
But I would definitely vote for sparing the complexity and effort for now.

Thanks for further opinions! I think there are many valid/reasonable points. As proposed and as a compromise for the time being, shall we go ahead with the less complex first approach for now and get our feet wet/get some experience? Introducing a dedicated resource in the Garden API can always be done later with (probably?) relatively manageable effort.

@timebertt Thanks for your feedback. Let me reiterate a few basic points:

My intention is to propose a mechanism that works in general, not just for shoots that could not be migrated and had to be forcefully restored.
If the problematic situation on the old seed is a persisting one, the cleanup should not be expected to work no matter how we implemented it, and we likely have a bigger problem than cleaning up leftover resources. I would focus on this situation, I regard it as exceptional, and one that perhaps doesn't require cleanup at all, but more drastic measures.
Cluster resources live the in the seed, and there are many seeds per landscape. Only resources in the garden cluster allow for easy visibility across seeds.
Cluster resources are not the only leftover resources (there are also namespaces, backup entries, and DNS owners). Detecting all possible leftover resources in order to trigger the cleanup would increase the complexity considerably.
Logs and events are not really "easy" as an indication that something is happening / failing and why, compared to a status of a resource, especially if they are associated with a seed resource.
The Cluster resource doesn't have a status and so far was not intended to be actively reconciled. Adding a status to this resource as an afterthought and reconciling it to perform cleanup would be hackish and confusing.
We may need to control the way cleanup is performed, e.g. some cleanups need a grace period as I pointed out. With a resource this could easily be added and implemented properly. Without a resource we would need to rely on annotations on existing resources. I also consider this hackish compared to using a proper resource.
I don't believe that garbage collection mechanims in Kubernetes could be used as an example for what we need to do here. I also don't think that if they needed anything similar, they would implement it by repurposing existing resources in ways they were not originally intended to be used.
I actually looked into how the cleanup mechanism could be implemented using the Cluster resource and I really didn't like the implications. It would be a controller unlike any other controller have implemented so far. I am not sure we would like this "novel" experience.

All in all, we may save the "complexity and effort" of introducing a new resource, but only at the expense of (in my opinion, worse) complexity and effort of properly detecting, controlling, and reporting cleanup using existing resources, and at the price of using them in ways they were not intended to be used, achieving worse usability of the entire mechanism.
@rfranzke I am not even sure how to implement this "less complex first approach" properly at the moment, and the implementation of the controller using a dedicated resource is in a rather advanced stage, see #5150. I would propose to have a short sync to decide how to proceed.

A few short replies to "defend my points":

Cluster resources are not the only leftover resources (there are also namespaces, backup entries, and DNS owners). Detecting all possible leftover resources in order to trigger the cleanup would increase the complexity considerably.

I think, my point was misunderstood. Let me try to rephrase it:
I would only use either the Cluster resource or the corresponding Namespace as a trigger for the cleanup mechanism. This would be equivalent to triggering the whole cleanup logic by deleting the ShootLeftover resource.

The Cluster resource doesn't have a status and so far was not intended to be actively reconciled. Adding a status to this resource as an afterthought and reconciling it to perform cleanup would be hackish and confusing.

The Cluster resource is still not supposed to be "reconciled". The shoot controller should simply watch it as one of the "owned objects" that it created. The object that the controller "reconciles" is still the shoot, and the fact that it's gone causes the leftovers to be cleaned up appropriately.

We may need to control the way cleanup is performed, e.g. some cleanups need a grace period as I pointed out. With a resource this could easily be added and implemented properly. Without a resource we would need to rely on annotations on existing resources. I also consider this hackish compared to using a proper resource.

We could simply add a deletion timestamp to the cluster resource (either in the future and only then cleanup or start cleanup once a grace period after the timestamp has elapsed). I wouldn't consider this hacky at all, as it uses the normal API machinery.

I would propose to have a short sync to decide how to proceed.

+1

We could simply add a deletion timestamp to the cluster resource

This is not enough, we need to specify the actual grace period somewhere, either as a duration or as another timestamp (some cleanups do require a grace period, others don't)

I would only use either the Cluster resource or the corresponding Namespace as a trigger for the cleanup mechanism

So if the resource that is used as a trigger is gone for whatever reason, nothing will happen, even if there are still other resources left.

The Cluster resource is still not supposed to be "reconciled" ...

So we will then be reconciling the shoot and reporting the cleanup progress / errors information to a status (and events) of a different resource, namely the Cluster. This is partly what I referred to as "unlike any other controller" above. I think there is a reason why controllers are usually not implemented like this.

In a discussion with @rfranzke, @timebertt, and @plkokanov we decided to adopt the "new resource" approach (the third one listed in https://github.com/gardener/gardener/issues/5173#issuecomment-995562573). The main arguments for this are:

We regard this as a general mechanism that could also be used for "forceful deletion" of clusters (also called "purge" or "drop cluster", see https://github.com/gardener/gardener/issues/3110#issuecomment-738745082), in addition to the "forceful restoration" introduced with #5123.
Although forceful restoration is expected to be rare, forceful deletion, if offered as an option to users, will be used much more often, and so the cleanup mechanism does require optimal visibility for progress and errors. Only resources in the garden cluster allow for easy visibility across seeds.

The other arguments listed in https://github.com/gardener/gardener/issues/5173#issuecomment-998582070 are also applicable, but not considered critical.
The provisional name for the new resource is ShootLeftover, although it could still be changed if there are better proposals. Since the resource stands as a "surrogate" for the (deleted or migrated) Shoot, it should contain Shoot in its name. As we are dealing with cleaning-up of "leftover" or "orphaned" resources in the seed, ShootLeftover is perhaps as good as any other name.
The first implementation proposed with #5150 will only be tested for fully-reconciled and "half-migrated" shoots, so it could be used with "forcefully restored" shoots. This is also the simpler case, as it does not require any infrastructure to be actually deleted, since it's still in use by the shoot. Later on the implementation could be adapted for the "forceful deletion" case.

OK, what's the status here? It seems, @timebertt (initially) and myself would rather pick option #1 with less effort while @stoyanr and @rfranzke (and then possibly also @timebertt) would like to pick option #3 with a way to report issues back into the garden cluster.
Whatever we plan to do, we should do it and close CPM (actually, this also covers forceful deletion and not only CPM).
If nobody can take the decision, I will: Clearly option #1. Reasoning above. We must trust our code and cannot add artificial resources for everything that can go wrong - we must make sure our controllers fix the state. Also, I doubt option #3 will be implemented by anyone anytime soon, so it's unrealistic anyway and we cannot keep this issue open forever.

Closing this in favour of #6302


Add Taproot Wizards collection

This is the full Taproot Wizards collection as of today, complete with traits for the non-honoraries. 🧙
The current supply is 2106, but some final honoraries will be given out over a longer period of time until the collection reaches a final supply of 2121 (I will open new PRs over time to keep the JSON up-to-date).
This data is already in use on taprootwizards.com and ordiscan.com, so you can see what implementing this JSON will look like there.

Nice


TangNano 9k clocking from external source working only in some configurations at random

blinky.v don't work (tested on 2 boards), but blinky-osc.v works fine.
After adding --enable-gobals works again, but after some unrelated changes in v file broken again
(after rebuild & reflash)

Can you specify at which --seed you steadily get a non-functioning image?
This makes it easier to deal with random bugs:)

Can you please check with the latest nextpnr and apicula?

ок, when some time

Should work after https://github.com/YosysHQ/apicula/pull/199


fix popper's behavior when it doesn't have any parents (#136)

Solves this: #136

May you add a test for this case?

About test: I was planning to work on unit tests for the rest of the functions on the next weekend (can't do that sooner), so it will be covered in there. Writing a functional tests is a nightmare, maybe need to do something about them as well...
This fix doesn't break anything, all the existing tests are green locally.

I was thinking about a simple functional test like the others we already have, unit tests make sense to me to check stuff that doesn't interact with DOM (IMHO) so I wouldn't bother trying to write an unit test for this case.

By the way, SauceLabs is in maintenance until Monday so we have time before we are able to merge this PR.

I would strongly disagree with the 'simple, like others we have' :D There has to be a better way to do this...
Done, renamed and tested.

@nadiam84 any idea to make the tests simpler is more than welcome 🙂


Port new features or bugfixes from Source

In the discussion below we can talk about commits to add to this to-port list.
Paste the whole commit text even if you intend to port only a part of its code.
When a commit is ported, reference to this issue in the commit message and add a comment to this issue specifying which functionality was ported from which commit.
This message will be edited and the text made strikedthrough.

To be tested more and eventually port.
Revision: a622737b2be9495d264091d7632af4987bfbfcfd
Author: Coruja<EMAIL_ADDRESS>Date: 13/06/2016 22:58:50
Message:
Fixed: Boat/ship parts resetting TYPE after use 'turn' commands.
To be tested more and eventually port.
Revision: acc1eb61d49e9c8d898027f64eafb8ee9076d343
Author: Coruja<EMAIL_ADDRESS>Date: 17/06/2016 09:11:42
Message:
Fixed: Paralyze / Paralyze Field making NPCs flood too many attack actions
Fixed: Console error when for some reason an NPC got created/moved to an invalid region
To be tested more and eventually port.
Revision: ffc3a52226fa3fa65ac40b3bf5476e5aa2e4f571
Author: Coruja<EMAIL_ADDRESS>Date: 22/06/2016 18:24:07
Message:
Added: Support for colored multis on target functions (only compatible with HS clients <IP_ADDRESS>+)
Revision: aada1eb2fcb12b5b3564be6aa5a7b23e5d91a9e8
Author: Coruja<EMAIL_ADDRESS>Date: 27/06/2016 23:44:21
Message:
Fixed: Function f_onchar_delete not being called if the player char get deleted in any other way different from client Character Selecion menu
To be tested more and eventually ported.
Revision: a79d64ef2bee889a3a63ac0a7d96f5defc0e0459
Author: Coruja<EMAIL_ADDRESS>Date: 27/06/2016 23:57:49
Message:
Fixed: Multi dynamic regions getting replaced by script static regions on server resync
Revision:<PHONE_NUMBER>896269766206db690f76a3785290b1
Author: Coruja<EMAIL_ADDRESS>Date: 30/06/2016 00:41:34
Message:
Fixed: Attack/Kill command on pets allowing select the pet itself as target, making it attack his owner
Revision: f26b39b9b40fba76660c36d57baa8387d3613272
Author: Coruja<EMAIL_ADDRESS>Date: 22/07/2016 22:52:03
Message:
Fixed: Security issue setting account login as chat name when newest clients try to setup the chat window for the first time and the char name is not available
Fixed: Invisible chars being incorrectly revealed by REVEALF_LOOTINGOTHERS reveal flag when picking items from the ground
Fixed: Return 0/1 on spell triggers not working correctly
Fixed: Function MOVENEAR not working correctly
To be discussed and eventually ported.
Revision: dd7a59b451e9d4d8d99c3bec15b330cf60dded2f
Author: Coruja<EMAIL_ADDRESS>Date: 02/08/2016 07:07:12
Message:
Fixed: Items inside trade window not firing @DropOn_Item trigger when the trade move the item to player bacpkack
Revision: 1fa0504b39e9df1074fb29121da2446926eb56b6
Author: Coruja<EMAIL_ADDRESS>Date: 03/08/2016 08:59:17
Message:
Changed: Max item capacity on containers changed from 255 to 125
This is required to make containers works properly on Enhanced Clients, because containers on these clients have hardcoded capacity of 125 items (OSI already uses this value since many years ago, even before enhanced client)
Revision: 5586c3db3ff6940a6d93c6d8062ccca1e195cbc2
Author: Coruja<EMAIL_ADDRESS>Date: 07/08/2016 06:54:07
Message:
Fixed: ARGN1 on char trigger @SkillPreStart not working correctly
Revision: 48ba5dc6e0e8be27b06208b31d128400eda47dd1
Author: Coruja<EMAIL_ADDRESS>Date: 12/08/2016 08:30:13
Message:
Fixed: Client war mode flag not being removed on death
To be tested more and eventually port.
Revision: 210563f9d22c4374e4faecdf92cd78ccd7114661
Author: Coruja<EMAIL_ADDRESS>Date: 13/08/2016 07:24:17
Message:
Fixed: Multi regions not reloading correctly after server resync
Also added a smart check to only reload it when needed (eg: AREADEF/ROOMDEF get changed on scripts)
To be tested more and eventually port.
Revision: c8223f203bbeb753ff0e1d3388db13e4df0b4d4a
Author: Coruja<EMAIL_ADDRESS>Date: 21/08/2016 05:29:13
Message:
Fixed: Internal check to prevent drop items inside walls preventing the item drop even when the wall is on another floor
Fixed: Message "Too many items here!" not showing correctly when items are dropped on areas with too many items
Revision: 30364c13a309452fe5fa2d28f264766c67b34e5d
Author: Coruja<EMAIL_ADDRESS>Date: 27/09/2016 02:07:55
Message:
Fixed: HTTP server not working correctly
Revision: 8fd75922705cbf38eda5130a65bbc91c020e418e
Author: ares<EMAIL_ADDRESS>Date: 06/10/2016 22:31:42
Message:
As we have experienced at Alathair, exporting chars is nearly always meant to export other chars but not the own char, a flag here would be neccessary to control that. The default case should be not to export SRC itself. but it could be optionally turned on using the bitflag 0100. So if you want to export chars including yourself use flag 6. If it should include items use flag 7. Otherwise 1 2 and 3 will not include SRC.
...Continues...
To be tested more and eventually ported.
Revision: d66893bfe79e5e359f1d01465f24bdabbd515a6f
Author: ares<EMAIL_ADDRESS>Date: 08/10/2016 20:10:14
Message:
Fixed a critical bug in background save mechanism where an unsaved offline player character disappears from worldsave when moved to an already saved sector.
Revision: 003321948c4694b5575c6072dec2d72db4a2e576
Author: Coruja<EMAIL_ADDRESS>Date: 17/10/2016 21:23:34
Message:
Fixed: NPCs losing 'statf_spawned' flag after server restart
To be tested more and eventually ported.
Revision: 72ff09966548b27829fcf2ed7608207ae6862d26
Author: Coruja<EMAIL_ADDRESS>Date: 12/11/2016 20:41:49
Message:
Fixed: Resurrect, Reveal, Meteor Swarm and Lightning spells showing effect animation even when EFFECT_ID=0 is set
[sphereCrypt.ini]: Added crypt key for classic clients 7.0.54 ~ 7.0.55 and enhanced clients 4.0.54 ~ 4.0.55
Revision: b054cd3277f26789ee2fbdd1cb7f96aa21d38127
Author: Coruja<EMAIL_ADDRESS>Date: 22/12/2016 19:09:09
Message:
Added: Missing buff icon for Criminal flag
I found this on ServUO repo, thanks for the help :P
Revision: bdc53e3cd70755a5add1c4b57819a2fef00d0245
Author: Coruja<EMAIL_ADDRESS>Date: 08/01/2017 19:23:28
Message:
Fixed: Function 'CRIMINAL 0' not updating char notoriety/buff when removing criminal flag
To be tested more and eventually ported.
Revision: 6e0f90f61fdd81d522143e35b6d968137c3d39ab
Author: Coruja<EMAIL_ADDRESS>Date: 25/01/2017 17:44:31
Message:
Fixed: Client encryption not being decrypted correctly on login process
Also reverted changes on packet 0BF 018 accidentally sent some commits ago
Revision: f1b5cffa0081d12aecf6600447ccae32cb752925
Author: Coruja<EMAIL_ADDRESS>Date: 21/12/2016 06:52:38
Message:
Fixed: Mass Curse spell not working correctly
Revision: 28b644628e76d3b837ecc960f5fb40d9bc920a40
Author: Coruja<EMAIL_ADDRESS>Date: 07/02/2017 21:59:56
Message:
Fixed: Char flag 'statf_hovering' (gargoyle fly ability) not clearing when gargoyle chars polymorph into non-gargoyle char ID

Probably more to add in the next days (i'm not done checking Source's changelog).

Closing, we are splitting ports into separate issues.


Not working on mobile?

Although my mobile browsers support the FileReader API (checked with demo at https://developer.mozilla.org/en-US/docs/Web/API/FileReader/readAsDataURL), the Leaflet.FileLayer demo does not work on my mobile. To reproduce:

open http://makinacorpus.github.io/Leaflet.FileLayer/ on Firefox for Android (48.0) of Chrome for Android (52.x)
click filelayer control and pick a gpx file -> file picker closes but nothing is diplayed on the map. No error message.

Hi @opoto and thanks for the feedback.
I've just tested it and it works for me on Chrome 52 on an Android (Oxygen OS in my case).
I have an issue with Firefox, where the control doesn't even respond. I'll investigate on this.
In the midtime, could you try wih another gpx file ?
I've tried with those :

http://destination.cevennes-parcnational.fr/data/api/fr/treks/39571/canayere.gpx
http://destination.cevennes-parcnational.fr/data/api/fr/treks/39571/canayere.kml

Indeed the problem came from my GPX.
With a correct GPX it now works fine both on Firefox and Chrome, at least in my application.
To help using your demo on small screens, I would suggest to add following meta tag to index.html:
<meta name="viewport" content="width=device-width,height=device-height, user-scalable=no" />
Sorry for the erroneous report, and thanks for this good plugin

Great, thanks for the feedback !
Yeah a more complete demo is coming and we forgot the viewport meta on the actual, you're right.
Thank you for pointing it out !


failing upload to PyPI

see this error: https://github.com/PaloAltoNetworks/pan-os-upgrade-assurance/actions/runs/5195017879/jobs/9367329833#step:6:29

This happened to a bug during CI testing. The release on PyPI that got accidentally pushed got yanked.
To prevent future problems PyPI secrets got replaced. It might be required to also skip 0.0.2 on this repo to successfully upload a new release to PyPI next time CI runs.


[Hotfix] File Sniffer

Purpose
Mitigate abuse
Changes
Add configurable async script to auto-detect spam
Deployment Notes
Add dict with necessary info to CeleryConfig.beat_schedule
Side Effects
None expected

Build fail unrelated; pypi seems to be acting up


Feature Request

Is it possible to add Binance Exchange to the available commands ?
thanks

It is possible. My current issue is actually what to call the command. I ended up using f for Bitfinex, but I don't know what would apply for Binance. Bittrex already uses b.

would using a B rather than b work?

Mixing caps is kind of a problem because of mobile users. I finished implementation. The command is currently n and works just like Bittrex's. Suggestions for the command name are appreciated.
(e.g. .tb n tnt gnt btc)


Pika CDN not working for Vuetify

I've noticed that now the CDN is able to offer Vuetify, however, it does not work. Here are some JSFiddle samples:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
The old @pika/web produces a working Vuetify ES Module, but the Pika CDN does not. I'm generating the ES Module running this from a terminal:
mkdir VuetifyESM && cd VuetifyESM
echo {} > package.json
npm i<EMAIL_ADDRESS>vuetify@version <-- version being one of 2.1.18, 2.2.34 or 2.3.0
npm i @pika/web --save-dev
npx pika-web

The CDN-offered Vuetify 2.2.34 and Vuetify 2.3.0 works if these changes are made:
Old:
import * as vue from<EMAIL_ADDRESS>import vue__default from<EMAIL_ADDRESS>
...

var require$$0 = /*#__PURE__*/Object.freeze(/*#__PURE__*/Object.assign(/*#__PURE__*/Object.create(null), vue, {
	'default': vue__default
}));
...

New:
//import * as vue from<EMAIL_ADDRESS>//import vue__default from<EMAIL_ADDRESS>
...

//var require$$0 = /*#__PURE__*/Object.freeze(/*#__PURE__*/Object.assign(/*#__PURE__*/Object.create(null), vue, {
//	'default': vue__default
//}));

import require$$0 from<EMAIL_ADDRESS>...

The CDN-offered Vuetify 2.1.18 works if these changes are made:
Old:
import vue from<EMAIL_ADDRESS>...

New:
import vue from<EMAIL_ADDRESS>...

It looks like something strange is happening when Rollup tries to convert the package from Common.js to ESM. Unfortunately, we can't do one-off fixes like the ones you reccomended.
It's a big package, and I'm having trouble understanding where the bug is, but Vuetify really should look into shipping ESM support. The team seems open to it, I'm sure a PR would be appreciated from them. You could even use something like https://github.com/developit/microbundle to automate the task for you. Just make sure that "module" points to ESM instead of the current CJS.


[SMALLFIX] Minor improvement in UFSFactoryRegistryRuleTest

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/16166/
Test PASSed.


Update the JSON.stringify

To disallow undefined and functions from being passed in.
JSON.stringify will return undefined if undefined or a function is passed in.
if we allow undefined and functions to be passed in, we would need to change the return value to be void | string to be correct. Since that would cause way more trouble for users of JSON.stringify, disallowing the problematic inputs seems like the correct approach here.

Does this type allow passing in an exact object (such as a value of type {| foo: 1 |} )?

@kassens yes

@nmn Could you import it and see what effect this would have on our internal codebases? It's a good way to gauge what the deploy burden would be.
This looks pretty reasonable, but we should make this change with care.

Crazy typelevel stuff with JSON.stringify and toJSON
https://flow.org/try/#0AQhQBcE8AcFNgFIGUDyA5AJAZ3AJwJYB2A5vgGaTAC8wAPACoB8AFAPoBcw9AlNY8BgDCAQwA2o2qBAhmU6SABkwZgxYcuwAD7AA3uAD2ydJ2a8q-egF8ANMAAenHZbP8cBEtzkhu1r11-yQmISsvKKymycAG76+AAmWroGRmgmLsAx8c58GbFxnmHASipMkVzpTtw+fiD0foygDXGwAMaiwrjwbcJYWIioaACsulI4wuD4LcBuRKQUqsz6AEYAVpz0ReWcQeKS0inYeLPklEoHMyQnAbVSjADcoJagoC36hDjAhPrgAGp51Mp0ilBgA6C5zSDMSoPV7vcDAfBYP7xAGmHLAsFHS4UZgAV0IzTIRFg+Rhbw+iORcQATKigQNQeCTlDkgM0jl8YTiXFnA8gA

Possibly better types:
https://fburl.com/l8kkhrvs

@nmn If we're trying to explicitly block JSON.stringify from returning undefined - which is not what JS does...

@stryju - JS returns undefined when undefined is passed in or when a function is passed in. This type bans those arg types and so you will only get string as output.
If you accidentally pass in undefined or a function into stringify it’s probably a bug and rather than trying to add every edge case to the types it makes more sense to disallow incorrect use cases in the types.
Second, it does not block the stringification of classes with the toJSON function. They still work.
Currently, functions are not banned because functions are also objects, and also classes that have a toJSON method returns undefined is not caught.
But the link I posted in my last comment does fix more of those problems. It’s a higher risk change though, so it’s not quite ready to be merged yet.

any new info on this one?

I've accepted the internal diff, @nmn can now choose when/if to land it


Sanitize Network API

Today the network API provides a lot of flexibility (connections/bindings).
This was intentional in order to allow developers and users to develop and test the networking capabilities.
At some point the flexibility should be removed in order to provide a more streamlined API.
This should probably take place before v1.

@dankenigsberg how shall we proceed here?

@fabiand, I don't have a clear vision how a clear API should look like. IMHO, UI should be thin and clear, APIs should be powerful.
Would you lay out more details for the criteria for a clear API? Could you give examples?

We plan to clean up the API for KubeVirt v1.
Please think about which things you want to eventually remove from the api
to not slip into v1.


Official way of setting is_staff and is_superuser

Does anyone know what's the "official" way of setting is_staff and is_superuser?
My IdP is sending the status as a "true" or "false" string in a specific attribute. However, simply putting the attribute in SAML_ATTRIBUTE_MAPPING is not enough as djangosaml2 will try to assign the string value to the boolean field on the user model where it'll raise an exception upon save.
At the moment I am working around that with a custom authentication backend which overrides the clean_attributes method and "booleanizes" the values there, but I wonder if there's a better way?
Questions:

Does SAML have the concept of "boolean" values? Do I just need to tell my IdP to send that value as a specific attribute and it'll automatically be interpreted as a boolean by djangosaml2?
If not, is there a better way to do this?
If not, should we have a better way? I feel like subclassing the backend for such a basic thing is overkill, and I'd prefer being able to pass arbitrary functions/lambdas in the SAML_ATTRIBUTE_MAPPING which will be called with the original value and return the transformed value. Then I could just set it to {"IsSuperuser": lambda v: [x == 'true' for x in v]} and be done with it.

Simply use a custom account app and add a @property getter and setter to handle that behaviour

Otherwise, the "stop feature" would be an Attribute post processor that can optionally rewrite the attrs upon some rules.
I implemented a similar approach in another library, called pymultildap
https://github.com/peppelinux/pyMultiLDAP/blob/5dcb32955f4ba0eda1300405c69885d6321f5945/examples/settings.py.example#L62
Would It Be a good feature for you?

Also here:
https://github.com/knaperek/djangosaml2/issues/192

I don't think the rewrite feature as in pymultildap is a good idea. It's a large amount of work to implement all potential rewrite operations and you still wouldn't be able to cover every case. Why not just use actual Python code, by passing a callable (which takes the original value as argument)?

I'd prefer a @property but yes, callable Just works. Feel free to close this issue if you're satisfied, I'd wait a week before doing that, if there won't be other posts

Hi @Rjevski is there any update on this?
Would you like to purpose a PR or have you found alternative solutions based on a custom user account model?
Let me know, I'd close this issues in days

I've worked around this by subclassing the SAML authentication backend and setting the attributes there. I do think however the package should be extended to take lambdas in settings directly. I'd say it's worth leaving this open for the foreseeable future as a discussion thread and see if other users come forward with their opinions.

On 20 Oct 2020, at 12:22, Giuseppe De Marco<EMAIL_ADDRESS>wrote:
Hi @Rjevski is there any update on this?
Would you like to purpose a PR or have you found alternative solutions based on a custom user account model?
Let me know, I'd close this issues in days
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Are you working on v0.50.0 or v1.0.0-rc (current main)?

I'm no longer working on that particular project (it was delivered and the client is happy ✨) so I don't remember, I think I was using ~0.30. I'm afraid I can't contribute any more details to this for now, but I would prefer to leave this discussion open in case someone else has a similar use-case and wants to share their thoughts.

On 17 Dec 2020, at 10:41, Giuseppe De Marco<EMAIL_ADDRESS>wrote:
Are you working on v0.50.0 or v1.0.0-rc (current main)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi! I was looking at the same issue actually.
I don't need to update the User model, so I didn't change AUTH_USER_MODEL but set SAML_USER_MODEL to a proxy model for User, like:
from django.contrib.auth.models import User

class MyUser(User):
    class Meta:
        proxy = True

    def process_entitlement(self, values):
        if 'specific-entitlement' in values:
            self.is_staff = True
            self.save()
        else:
            self.is_staff = False
            self.save()

And in settings I have
SAML_ATTRIBUTE_MAPPING = {
    'eduPersonPrincipalName': ('username', ),
    'eduPersonEntitlement': ('process_entitlement', ),
}

Now, a different option seems to be a different backend, like:
from djangosaml2.backends import Saml2Backend

class MySaml2Backend(Saml2Backend):
    def _update_user(self, user, attributes: dict, attribute_mapping: dict, force_save: bool = False):
        if 'eduPersonEntitlement' in attributes:
            if 'some-entitlement' in attributes['eduPersonEntitlement']:
                user.is_staff = True
                force_save = True
            else:
                user.is_staff = False
                force_save = True
        return super()._update_user(user, attributes, attribute_mapping, force_save)

At first I thought about the save_user function, but that has no access to attributes, and it's not called if there are no other updates.
Comments welcome to either approach - and maybe one of these is useful in the documentation?
Now I thought there was a third option that @peppelinux suggested; but I was unable to use the @receiver(post_authenticated) or @receiver(pre_user_save) from djangosaml2.signals - perhaps that requires a custom User model after all, though I tried with and without sender, and sender also set to get_user_model() or User. It could also be I didn't put it in the right place.)

Hi @pauldekkers
happy to see you here :)
Yes, I like your approach, so feel free to do a PullRequest to dev branch (dev, not master!)
I'll update docs asap

Thanks @peppelinux. So, both approaches? I was in doubt about the _update_user as it being 'internal', but it's the shortest and most flexible example actually and possibly calls user.save less times.

Yes, it would be great to having both, it's a good hint for developers!

The proxy model seems like a good approach in this case - it would've worked for me too but I didn't think about it at that time.

https://github.com/IdentityPython/djangosaml2/issues/299
the backend is the faster way to do that, everyone agree? :)


feat: add substition columns from nextclade to metadata

Description of proposed changes
This branch adds two additional columns from the nextclade output to the metadata.

@rneher This seems potentially really useful for some features we've discussed internally. Would you be ok with merging this as it is or are there concerns that this could break our downstream processes?


AsciidocFX in Ubuntu 18.04 LTS: is jdk 8 installation also required?

I would like to install AsciidocFX in Ubuntu 18.04 LTS.
The installation instructions say that I have to untar the package and run the following:
$ cd bin
$ ./AsciidocFX.sh

Am I also required to install jdk 8 or its installation is included in the installation of AsciidocFX?

Hi, just install and run, you don't need to install java. AsciidocFX has Java 12 bundled inside.

Hi, I'm closing the current issue. Let me know if you require further help.


Update package.json to include the repository

NOTE: This is not a bot. This change was made by and comments will be reviewed by humans. We are using this service account to be able to track the overall progress.
With the rise in supply chain attacks and OSS dependencies being used as a attack vector, Microsoft is working with our ecosystem partners, such as the Linux Foundation's OpenSSF, to enable OSS consumers to track packages back to their public sources.
We've identified that the following packages published to NPM do not report where sources can be found, typically accomplished by including a link to your GitHub repository in your package.json REPOSITORY field. This PR was created to add this value, ensuring future releases will include this provenance information.
If you do not want us to create such PRs against your GitHub repositories, or wish to provide any other feedback, please comment on this PR.
Published NPM packages with repository information:
• prettier-plugin-sorted
Description

Checklist

[ ] My code follows the code style of this project and yarn lint --fix runs successfully.
[ ] I have updated the documentation where necessary.
[ ] New code is unit tested and all current tests pass when running yarn test .

Is there anything that is needed to land this pull request ?

ls there anything else I can do to land this pull request?

Is there anything that is needed to land this pull request?


Setting rustflags does not work with --target

Problem
It looks like cargo ignores the rustflags set by environment variables (RUSTFLAGS and CARGO_TARGET_X86_64_APPLE_DARWIN_RUSTFLAGS and CARGO_BUILD_RUSTFLAGS) when given --target. For instance, in a build linked against -liconv, cargo build succeeds when given the proper linker arguments, whereas cargo build --target <my actual target> doesn't:
$ printenv CARGO_TARGET_X86_64_APPLE_DARWIN_RUSTFLAGS
-C link-arg=-L/path/to/iconv/lib
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
$ cargo build --target x86_64-apple-darwin
   Compiling unicode-xid v0.2.1
   Compiling proc-macro2 v1.0.26
   Compiling syn v1.0.69
   Compiling autocfg v1.0.1
   Compiling serde v1.0.125
   Compiling serde_derive v1.0.125
   Compiling typenum v1.13.0
   Compiling version_check v0.9.3
   Compiling memchr v2.3.4
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-m64" "-arch" "x86_64" <thousands of args that do NOT include -L/path/to/iconv/lib> "-lSystem" "-lresolv" "-lc" "-lm" "-liconv"
  = note: ld: library not found for -liconv
          clang-7: error: linker command failed with exit code 1 (use -v to see invocation)

If this is the expected behavior, how do I set the linker flags?
Notes
From the Compilation Options page, I understand that this "makes Cargo run in a different mode where the target artifacts are placed in a separate directory". However, as I understand it, this should only impact where the target artifacts are placed, not how the configuration is read.
Output of cargo version:
$ cargo version
cargo 1.53.0 (4369396ce 2021-04-27)

Thanks for the report!  Can you provide some more information, such as the project, or a minimal reproduction?  Can you run with the -v flag to print which commands are being run?
Just FYI, there are various ways flags will be ignored. When passing --target, the rustflags are ignored for build scripts and proc macros.

Sure, and thanks for the quick reply!
I can trigger this by adding a dependency on serde, for instance:

Cargo.toml:
[package]
name = "foo"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
serde = "1"

Cargo.lock:
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3

[[package]]
name = "foo"
version = "0.1.0"
dependencies = [
 "serde",
]

[[package]]
name = "serde"
version = "1.0.126"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ec7505abeacaec74ae4778d9d9328fe5a5d04253220a85c4ee022239fc996d03"

src/main.rs:
fn main() {
    println!("Hello, world!");
}

Running cargo build succeeds, but cargo build --target x86_64-apple-darwin fails with the error above.

I'm actually a little confused. I can't find a single mention of iconv in the serde codebase. Do you have any idea why it gets linked in?

Note: not only cargo doesn't add a -L/path/to/lib flag, but it looks like it overwrites DYLD_FALLBACK_LIBRARY_PATH. When running with -v, I see that it unsets DYLD_FALLBACK_LIBRARY_PATH and replaces it with an (apparently) cargo-crafted one that does not include the original value of DYLD_FALLBACK_LIBRARY_PATH.

Ah, yea, iconv is required for all apple targets due to libc.  macOS should include a global copy in /usr/lib/libiconv.dylib, do you not have that?
Cargo should only extend DYLD_FALLBACK_LIBRARY_PATH if it is already set, it should preserve any paths passed in.  That shouldn't be relevant for linking, though.  How are you calling it?  What is the value of DYLD_FALLBACK_LIBRARY_PATH and why are you overriding the default?

No, I don't have that it seems:
$ ls /usr/lib/libiconv.dylib
ls: /usr/lib/libiconv.dylib: No such file or directory

I worked around the problem by setting CFLAGS. I'm fairly new to macOS and assumed DYLD_FALLBACK_LIBRARY_PATH worked like a mix between LIBRARY_PATH and LD_LIBRARY_PATH, but obviously I'm wrong :)
How can I tell cargo (as opposed to telling the linker directly with CFLAGS) where to look for libiconv.dylib, if it's not in /usr/lib?

I'm a little curious, do you happen to know why libiconv is missing?  Which version of macOS are you using, and which platform (is it an m1/arm mac)?

Sure! It's a Big Sur, Intel Mac. Is libiconv expected to be shipped with macOS? Or does that get installed by Xcode? I don't have Xcode.

Yea, I looked it up, and in macOS 11, they switched to having a hidden cache of shared libraries (62986286).
Another thing that looks fishy is that your error message says clang-7.  Do you maybe have the wrong cc in your PATH?  Normal cc from Apple should just say clang: and the cc version should be at least 12.

Ok as mentioned I did not install the Xcode suite. I have a custom clang build, that's probably why it displays clang-7.
Is cargo expecting clang to install libiconv in /usr/lib?
By the way, thanks a lot for taking the time here!

Cargo doesn't deal with linking; rustc controls that process.  It assumes that -liconv can be found somewhere in the default linker paths.

I'm going to close, at it sounds like the issue here is using a custom clang that does not know about the hidden library cache in macOS 11.  You'll probably need to provide iconv somehow in the search page so that it can be found, or use the xcode clang.


add node-gyp configure to build script

node-gyp complaines about needing to run configure first, maybe it would be good to add that to the build script?

Experienced same issue.


Consider getting claude3 to upgrade code

it's powerful - and documents code well. can solve open issues.

https://x.com/deedydas/status/1774279208782700692?s=46&t=-tkSIrsyNobBjIvQ2IAQwQ


#NGG-63|adding sourceMap for typescript - in .tmp (serve) and in prod…

…uction with debug mode

@aryelu and @borislit are working on similar thing. they already managed to get source maps working for grunt serve, but I think you guys should sync and think together on solutions. copying all .ts every time the watch is triggered is too much, we need to either have a more efficient copy or avoid the copy altogether. (I have no problem with single time copy during build, but not in watch path)

We got it working when debugging UTs in browser aswell.


Fix links

I don't think this change is required.  The links in https://expressjs.com/en/4x/api.html#req and https://expressjs.com/en/5x/api.html#req (in the admonition under "Properties") seem to work just fine.


Fix --no-bail not throwing when running in default orderMode

Fixes #255.
I've also improved the error message to report the number of tasks that failed and any error messages that were in the error (which is most likely going to be none for the cli version since it spawns processes).

Sweet, LGTM


Add FJC logo to Sobre MVP

Add FJC logo to the "colaboração" section and rearrange present logos and spaces to comply with design at https://www.figma.com/file/Ny3rRkAQbvPJ5zSOYkIyLj/NAFILA?node-id=3896%3A25949

testado em iphone ( safari e chrome)
windows - chrome


Specify the nature of sid_matrix

https://github.com/nmorale5/NoahYixiaoHashCode.jl/blob/449e3d8b75060206bb4a287c18d7621f811e54b2/src/routing_problem.jl#L14
Some of your code will error if sid_matrix is anything else than a sparse matrix. You can specify it either in the docs or as a type constraint (the former being more "Julian" to allow for other uses of your struct)

I have specified that in the docs.


Reduce Cypress run-time in CI

Overview
In web's CI pipeline we have two workflow files that trigger runs when a PR is made against main, develop, or releases/**:

.github/workflows/pr.yml
.github/workflows/pr-cypress.yml.

In each workflow, we use actions/cache@v2 to cache our node modules, so we only run yarn install --frozen-lockfile when we have a cache miss.
The current implementation has a number of inefficiencies:

If we have a cache miss on the node modules, we rebuild the node modules on each worker. There is currently one worker assigned to pr.yml, and 3 assigned to pr-cypress - so we do this 4 times, when 1 would suffice. We could instead implement a discrete build step, that all workers will wait on, instead of each worker rebuilding their own.
Similarly, within the Cypress runner we have a Cache Cypress binary step, which again, in the event of a cache miss, runs once on each of the 3 workers.

Something like actions/upload-artifact@v2 and actions/download-artifact@v2 might be of use here - please reach out to @0xdef1cafe once you've identified a path forward with a request to whitelist any actions that need to be enabled in the web repo.
Reference
Current workflow examples:

The Run Cypress workflow
The commitlint-lint-typecheck-test-build workflow

Acceptance Criteria
Reduce our total CI worker time by implementing discrete build steps for both Node and Cypress binaries.
Concretely, this would look something like:

A discrete step that replaces Cache dependencies in pr.yml, and Cache central yarn modules in pr-cypress.yml, and is waited on
A step that replaces Cache Cypress binary in pr-cypress.yml, and is waited on

Each of these steps should run at most each time the CI workflow is triggered.
Note, there is no expectation to reduce the duration of the CI process (though it'd be a welcome bonus!) - only the total worker time used each time CI is triggered.
Screenshots/Mockups
No response
Ownership

[X] If my bounty needs engineering or needs product I have added the respective labels on the right
[X] As the sponsor of this bounty I will review the changes in a preview environment (ops/product) or review the PR (engineering)

@Soptq this will likely assist you to meet best practice: https://docs.cypress.io/guides/continuous-integration/introduction#Caching


Add comet scorer

Added comet scorers for validation in NMT training.
I left progress_bar=True, num_workers=0, batch_size=64 and gpu=0 for cpu inference, should it be like that by default and should it be modifiable via config ?
I did not modify tests as it would greatly extend the tests duration (downloading comet models and inferencing on cpu).
I also took the liberty to lightly modify wmt17 recipe/doc to make it more beginner friendly.

Thanks for your PR! I think it would be better to use a single block of code for all comet-like scorer and add a setting for the model path at start-up.

In a real world, COMET requires a GPU so it would be great to unload the model being trained or/and specify another gpu for comet. What do you think ?

Sorry I need clarifications, if we keep the single block of code approach, how can I precise which comet model to load without the model_name argument ? I could imagine a scenario where we use the "metric" in the list in @register_scorer(metric=[...]) but I don't see how I could implement it without modifying other scorer loading logic.
Thanks !

Continuing the discussion here:
There are multiple way for doing this, off-loading current model to run comet scoring on gpu as @vince62s suggested, we could run it parallel of the training (subprocessing a comet cpu scoring), dedicating a second gpu to score.
That's why I first implemented it on cpu during eval (to not mess with vram) and have it working transparently for a naiver user.
What would you recommend ?

I think the easiest for 1) user convenience 2) speed is to unload the model being trained, load the comet model on the same gpu, and relaod the trianed model after scoring. Scoring on cpu will be way too slow and dedicating a second gpu will be a nightmare to handle from the user standpoint

Tested how vram was impacted with this method:
Loading a comet model does not seem to directly load vram
self.comet_model = load_from_checkpoint(comet_model_path)
but after running prediction
            score = self.comet_model.predict(
                data, batch_size=64, gpus=1, num_workers=0, progress_bar=True
            )

This leaves a 300mib trace in vram.


Move GOGC where it belongs

Only for testing – I'll open this fix in github if it works

Didn't improve memory problems, but anyway I'll fix it for our repos


intial logformat: " []: "

    set `LstdFlags` to `Ldate | Ltime | Llevelinitial` as this is
    more straightforward for the user and simpler to match for
    intrusion prevention software as fail2ban or sshguard.

Fixed indentation, replaced spaces by tabs - sorry for that.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@cbd2beb). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master   #9128   +/-   ##
========================================
  Coverage          ?   41.1%
========================================
  Files             ?     547
  Lines             ?   71613
  Branches          ?       0
========================================
  Hits              ?   29434
  Misses            ?   38443
  Partials          ?    3736

Impacted Files
Coverage Δ

modules/log/flags.go
100% <ø> (ø)

Continue to review full report at Codecov.

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

Although I can see why you might want that, the reason why the stdflags are the way they are is so we can actually see where errors are coming from when people report errors.
If we change the default to not report the location, when people who are unable to change the logging configuration - either through not being able to easily reproduce the error, insufficient rights or even through incompetence - then we will find it even more difficult than we do now to provide support.
I wrote the access logger precisely to provide an NCSA compatible log file for fail2ban and other standard tools. Is this not sufficient? If not perhaps we could improve that.

Another option is just create another file logger with the appropriate flags set and you can even set an EXPRESSION so that only fail2ban appropriate log messages even up there.

There's already a guide for setting up fail2ban:
https://docs.gitea.io/en-us/fail2ban-setup/
fail2ban is actually pretty flexible. As long as the info is there, you can make it parse almost anything.

of course fail2ban can handle that.
my the point is that
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
is a nice human readable log, where as
2018/04/26 18:15:54 routers/user/auth.go:169: [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx introduces misalignment, is harder to read and bloat logfiles.
from my point of view, this logging is debug-mode.
of course I can set the option for a logger in the app.ini, however for every new introduced logger I've to adapted the app.ini.
I can see the point of @zeripath as well, but I assumed that grep will do the job in most cases, and for the harder cases the user might be able to change the logging to debug-mode  … it was just a suggestion

No suggestions are good!
It might be that we should suggest a fail2ban log with specific config which would make things easier/cleaner for fail2ban.
I was just responding to say why the default flags are the way they are and to say that they're really helpful for us to debug problems.


Add missing property DOMNamedNodeMap::$length

https://www.php.net/manual/en/class.domnamednodemap.php#domnamednodemap.props.length

Hi @ondrejmirtes
this property is already declared in phpdoc and can be resolved successfully

this property is already declared in phpdoc and can be resolved successfully
NB: there is no type in the property declaration.

NB: there is no type in the property declaration.

@b1rdex fixed in scope of https://github.com/JetBrains/phpstorm-stubs/commit/4b340f6bc6c322b450cc3246b29dde2a4bed7783


Inspection not discovering quarto-shiny type

Was working with Garrett on using the publisher during demos at conf.
His repo projects: https://github.com/posit-dev/posit-conf-survey
He has multiple projects all stuck into one subdirectory.
Inspection of dashboard.qmd returned quarto but didn't return a choice of quarto-shiny.
It also incorrectly detected that it required python, but it wasn't.

Verified functioning with revealjs Quarto doc.


Showing proper error while creating a csr ndarray which is not 2D in shape.

Description
Fixes (partially) https://github.com/apache/incubator-mxnet/issues/13193.
We were allowing non 2D NDArrays to be created as a CSR that caused inconsistencies and also caused a crash when one tried to access .data on a CSR Matrix. The crash was coming from here : https://github.com/apache/incubator-mxnet/blob/master/src/operator/tensor/cast_storage-inl.h#L238.
The other places constructing CSRNDArray are already guarded by the shape checks.
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] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Does this fix the elemwise_mul issue?

Does this fix the elemwise_mul issue?

In that single issue there are two issues essentially, and both are independent of each other.
I'll open a separate issue to track the elemwise_mul operator issue. Will post the issue link here.
Currently swamped with other tasks, so will get back on this early next week :)

@piyushghai could you take a look at the CI failure? thanks!

@piyushghai Gentle ping..

@mxnet-label-bot Update [pr-work-in-progress]

Closing this.
Will reopen a new one after raising a github issue for the error message.


[WIP] Add local GeoServer instance

Add local setup to include GeoServer

I think I will close this, @meomancer said to push to v3 branch first.

Coverage remained the same at 39.611% when pulling dae0165c47efdb4d0a24f0f5260968486fdbc154 on lucernae:add_geoserver into e2862c1d5793ac5f41af52f9a9467e56952dff72 on healthsites:develop.


X-Ray Integration - is there a property or setting for that?

Sorry -don't see a feature request list or discussion forum. But adding the x-ray integration would make this production ready.

This is possible while setting up the mapper:
// wrap client with AWS X-Ray
const dynamoDbClient = AWSXRay.captureAWSClient(new AWS.DynamoDB());

// setup the mapper
const mapper = new DataMapper({
    client: dynamoDbClient,
    ...
});


Just wanted to say thanks

Thank you for the work you've done to make and maintain this layout. I am typing this (slowly) on my freshly installed Norman keyboard layout. I especially enjoy the roll with IN. (And thanks to the community that helps support the layout innovation.
Just curious...
What finger do you use for l, j and capital J?

I use my right ring finger for l, and right pointer for j and J.

And I use my left pinky to shift on almost every key

Got it, thank you!
I'm still familiarizing myself, that said... living on the home row is way
more fantastic than I expected. The switch makes me wonder why I waited so
long.
Which fingers do you use for F and U. I find that it requires a reach with
my pointer finger and it is pretty easy with my middle finger (particularly
F)... but using my middle finger costs comfort/speed on the next key. So
I've been switching around, but I'm curious how you think about it.
Thanks David.
On Wed, Jan 11, 2017 at 7:06 AM, David Norman<EMAIL_ADDRESS>wrote:

And I use my left pinky to shift on almost every key
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/deekayen/norman/issues/13#issuecomment-271713232, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AF0kPdDscmL76uUnuQpKNYStTjmmikc0ks5rRAD4gaJpZM4Lda05
.

--
Sebastian H. Wells
Epic Impact | Director of Marketing
415.513.7629 | www.linkedin.com/in/sebastianhwells

Also -- do you know how I might add Norman to my android?
On Wed, Jan 11, 2017 at 1:13 PM, Sebastian Wells <
<EMAIL_ADDRESS>wrote:

Got it, thank you!
I'm still familiarizing myself, that said... living on the home row is way
more fantastic than I expected. The switch makes me wonder why I waited so
long.
Which fingers do you use for F and U. I find that it requires a reach with
my pointer finger and it is pretty easy with my middle finger (particularly
F)... but using my middle finger costs comfort/speed on the next key. So
I've been switching around, but I'm curious how you think about it.
Thanks David.
On Wed, Jan 11, 2017 at 7:06 AM, David Norman<EMAIL_ADDRESS>wrote:

And I use my left pinky to shift on almost every key
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/deekayen/norman/issues/13#issuecomment-271713232,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF0kPdDscmL76uUnuQpKNYStTjmmikc0ks5rRAD4gaJpZM4Lda05
.

--
Sebastian H. Wells
Epic Impact | Director of Marketing
415.513.7629 <(415)%20513-7629> | www.linkedin.com/in/sebastianhwells

--
Sebastian H. Wells
Epic Impact | Director of Marketing
415.513.7629 | www.linkedin.com/in/sebastianhwells

I use my pointer for F and U, however if you want to get into specifics on which finger to use, I suggest you study Sean Wrona, who doesn't consistently assign a finger to a key. He also doesn't bother with an "optimized" layout.
Workman and Norman were added to xkeyboard-layout around the same time, but Workman was promoted to a full layout while Norman got stuffed to extras in a hidden config menu.
https://bugs.freedesktop.org/show_bug.cgi?id=56998
https://bugs.freedesktop.org/show_bug.cgi?id=71453
When we look at getting Norman added to things like Android, we first need to get it promoted to a full layout in xkeyboard-layout, which will make it a first-rate option in ChromeOS alongside QWERTY, Colemak, and Workman. When the Android devs can see it alongside that list, we'll have a better chance of getting it in ChromeOS (or even iOS). Otherwise, we have to campaign for it to be added to something like Swiftkey.
The problem with adding Norman to Android is that's a primarily mobile platform. Two-thumb typing from the sides of a screen is an entirely different optimization process than typing with all fingers, so Norman as-is isn't appropriate for typing on your phone. I wiped out all my promotion of the mobile Norman variant because I couldn't see a clear path to implementing it. I'd have to spend some time to re-find it or even more to re-create it.

I forgot I called this the workman-m layout when I put it together. If I do anything with it, I'd be renaming it to Norman-m.

@SeabassWells  Since you were just saying thanks, another way you could show it would be to go add some links or a thumbs up to the merge request at https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/merge_requests/24 to promote norman from Extras to Base in xkeyboard-config.


improve contributing_guide.md and related content

rename data_structures.md to internals.md, all implementation details
will go into this document in the future
why JuiceFS uses low level FUSE API
refactor content structure

pr ready, translation done @xiaogaozi


Remove generated YAML templates for fuse

The fuse templates were overlooked in #11321
Remove them from the repo, as they are automatically generated.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9271/
Test FAILed.

Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 2.487 sec <<< FAILURE! - in alluxio.client.file.MetadataCachingBaseFileSystemTest
openFile(alluxio.client.file.MetadataCachingBaseFileSystemTest)  Time elapsed: 0.044 sec  <<< FAILURE!
org.mockito.exceptions.verification.TooManyActualInvocations:
fileSystemMasterClient.getStatus(
    /dir/file,
    <any>
);
Wanted 1 time:
-> at alluxio.client.file.MetadataCachingBaseFileSystemTest.verifyGetStatusThroughRPC(MetadataCachingBaseFileSystemTest.java:134)
But was 2 times. Undesired invocation:
-> at alluxio.client.file.BaseFileSystem.lambda$getStatus$8(BaseFileSystem.java:261)
	at alluxio.client.file.MetadataCachingBaseFileSystemTest.verifyGetStatusThroughRPC(MetadataCachingBaseFileSystemTest.java:134)
	at alluxio.client.file.MetadataCachingBaseFileSystemTest.openFile(MetadataCachingBaseFileSystemTest.java:121)
openFile(alluxio.client.file.MetadataCachingBaseFileSystemTest)  Time elapsed: 0.402 sec  <<< FAILURE!
org.mockito.exceptions.verification.TooManyActualInvocations:
fileSystemMasterClient.getStatus(
    /dir/file,
    <any>
);
Wanted 1 time:
-> at alluxio.client.file.MetadataCachingBaseFileSystemTest.verifyGetStatusThroughRPC(MetadataCachingBaseFileSystemTest.java:134)
But was 2 times. Undesired invocation:
-> at alluxio.client.file.BaseFileSystem.lambda$getStatus$8(BaseFileSystem.java:261)
	at alluxio.client.file.MetadataCachingBaseFileSystemTest.verifyGetStatusThroughRPC(MetadataCachingBaseFileSystemTest.java:134)
	at alluxio.client.file.MetadataCachingBaseFileSystemTest.openFile(MetadataCachingBaseFileSystemTest.java:121)

alluxio-bot, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9272/
Test PASSed.

alluxio-bot, merge this please.


[DRAFT] - Vote text for RPIP-39

Adding PR here just for line-comments if anyone is interested

RPIP-39 Checklist:
Rocket Pool Vote Text Checklist

[ ] Vote text should include the following:

[ ] A short one-line summary intended to display effectively on the snapshot vote-listing page.
[ ] Context as to the reason for the vote.
[ ] A clear and concrete explanation of the possible outcomes of the voting process.
[ ] Links to relevant resources or further context.
[ ] A link to a relevant discussion thread on the Rocket Pool forums.

[ ] Ensure that all URLs point to the intended destinations.
[ ] Ensure the vote text is presented in a neutral manner.

[ ] The issue of framing bias has been considered and mitigated where possible.

[ ] RPIP Editors have reviewed vote text.
[ ] Ensure a relevant representative of Rocket Pool Ltd has approved the vote text.

Rocket Pool Vote Checklist
If vote has attached RPIP

[ ] The RPIP is present in the RPIP github repository.
[ ] The RPIP Draft Checklist has been completed for this RPIP.
[ ] RPIP has been given final status in the main branch of the official RPIP repository.
[ ] The RPIP Finalize Checklist has been completed for this RPIP.

Always

[ ] The vote has met the requirement for 'promising community sentiment'

Usually demonstrated by a poll on the RP forum that is open for at least 7 days.

[ ] Vote text has been completed for this vote.
[ ] The Vote Text checklist has been completed for the final iteration of the vote text.
[ ] Think about this vote for five minutes by the clock. Attempt to confirm that what you're doing makes sense.
[ ] Obtain confirmation from a relevant party of Rocket Pool Ltd that they intend to post the vote.

RPIP-41 Checklists
Rocket Pool Vote Text Checklist

[ ] Vote text should include the following:

[ ] A short one-line summary intended to display effectively on the snapshot vote-listing page.
[ ] Context as to the reason for the vote.
[ ] A clear and concrete explanation of the possible outcomes of the voting process.
[ ] Links to relevant resources or further context.
[ ] A link to a relevant discussion thread on the Rocket Pool forums.

[ ] Ensure that all URLs point to the intended destinations.
[ ] Ensure the vote text is presented in a neutral manner.

[ ] The issue of framing bias has been considered and mitigated where possible.

[ ] RPIP Editors have reviewed vote text.
[ ] Ensure a relevant representative of Rocket Pool Ltd has approved the vote text.
[ ]

Rocket Pool Vote Checklist
If vote has attached RPIP

[ ] The RPIP is present in the RPIP github repository.
[ ] The RPIP Draft Checklist has been completed for this RPIP.
[ ] RPIP has been given final status in the main branch of the official RPIP repository.
[ ] The RPIP Finalize Checklist has been completed for this RPIP.

Always

[ ] The vote has met the requirement for 'promising community sentiment'

Usually demonstrated by a poll on the RP forum that is open for at least 7 days.

[ ] Vote text has been completed for this vote.
[ ] The Vote Text checklist has been completed for the final iteration of the vote text.
[ ] Think about this vote for five minutes by the clock. Attempt to confirm that what you're doing makes sense.
[ ] Obtain confirmation from a relevant party of Rocket Pool Ltd that they intend to post the vote.


WMS ID # 11698: Updates for MC PRE2981 (Updates for Lab 4,8,10&11). Updates for HOL 2952 (Updated Lab4)

Add here your WMS ID
11698
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[x] All filenames are lower case (including folders, images, files, etc.)
[x] Filenames are descriptive
[x] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[ ] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[x] Image references in markdown contain an alternate text

Please approve Pull Request # 67 -- WMS ID # 11698 -- [Updates for MC PRE2981 (Updates for Lab 4,8,10&11). Updates for HOL 2952 (Updated Lab4) Thank You!

Thanks, @carmenberdant1. We are not using any private information as the lab is a temporary environment, and that info is non-routable info that will be destroyed after the masterclass. I have checked the numbering for the change-license-type-using-oci console and it is all fine for me. Thank You

Hello, @carmenberdant1, The Compartment Names are fictitious, and the IPs listed are private IPs that are non-routable. Without direct access to the tenancy, they are not accessible, and the environments are temporary and redone after each event. Thank You


Date picker and dates don't follow users language

Bug Report
Recently I reported the issue of the Date picker field not being localized and you released an update fixing it on the 1.6.6 release. However, the localization only occurs when you enable the localization option of the payload.config.ts file, but it doesn't localize it if you have it disabled and the user has their Admin UI language set to any other than English.
My customers mainly use Spanish-only content, so I don't need to enable the localization feature, but I do need the Admin UI to be in Spanish. So if I choose to have the Admin UI in Spanish under my account's preferences, all of the date pickers and every place where the date gets displayed is still in English. See video for context:
https://user-images.githubusercontent.com/47041342/217619798-6f34218b-9206-45b9-a136-2319137bc6e0.mp4
As you can see, I don't have content localization enabled, but I do have my user set to Spanish and I still get al of the dates formatted in English as well as the date picker. I hope I was able to explain myself correctly.
Steps to Reproduce

Create a simple Payload project without localization enabled
Create a collection with a date field
In the Admin UI, set your user's language preference to Spanish.

Other Details

Payload: 1.6.6

Crystal clear. We're on it. Thank you for the detailed write-up. Expect a fix shortly!


fix: use Config.ProjectConfig

Summary
This PR solves #4028

Test plan

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 95.987%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
4055

Relevant Lines:
4154

💛  - Coveralls

thank you @ologbonowiwi


cannot froze a subclass

To continue on my previous issue, I would like to froze a sublcass but I can't manage to make it work. As you manage to make it work in BoxList what am I missing ?
class toto(Box):

    def __init__(self, valeur):

        super(Box, self).__init__({"valeur": {"valeur": valeur}}, frozen_box=True)

truc = toto("truc")

truc.valeur = "toto"

Thank you very much. So let's expand a bit my question. My final goal is to create a translator object. The user should simply provide a language and I programmatically fetch and sanitize the dictionary before serving it as a Box of Box, that's why I'm interested in using a subclass that does not expose **kwargs and *args.
modifying your small example I can do this :
class toto(Box):
    def __init__(self, valeur):
        dict_ = {"valeur": "me"}
        super().__init__(dict_, frozen_box=True)

which work as expected. When I try to expand it to my real Translator object on the other end I get the foollowing error:

TypeError: init() got an unexpected keyword argument 'default_box'

Do you have any clue where it's coming from ?
Could it be related to the fact that I'm not overwritting __new__ ?
Note that if I'm slighty changing the following code doing:
super(Box, self).__init__(dict(**private_keys, **ms_boxes), frozen_box=True)

It works but the "root" box is not frozen

here is the skeleton of the class to help you understand what I try  to do :

class Translator(Box):
    """
    The translator is a Python Box of boxes. It reads 2 Json files, the first one being the source language (usually English) and the second one the target language.
    It will replace in the source dictionary every key that exist in both json dictionaries. Following this procedure, every message that is not translated can still be accessed in the source language.
    To access the dictionary keys, instead of using [], you can simply use key name as in an object ex: translator.first_key.secondary_key.
    There are no depth limits, just respect the snake_case convention when naming your keys in the .json files.
    5 internal keys are created upon initialization (there name cannot be used as keys in the translation message):
    -   (str) _default : the default locale of the translator
    -   (str) _targeted : the initially requested language. Use to display debug information to the user agent
    -   (str) _target : the target locale of the translator
    -   (bool) _match : if the target language match the one requested one by user, used to trigger information in appBar
    -   (str) _folder : the path to the l10n folder

    Args:
        json_folder (str | pathlib.Path): The folder where the dictionaries are stored
        target (str, optional): The language code (IETF BCP 47) of the target lang (it should be the same as the target dictionary). Default to either the language specified in the parameter file or the default one.
        default (str, optional): The language code (IETF BCP 47) of the source lang. default to "en" (it should be the same as the source dictionary)
    """

    _protected_keys = ["find_target", "search_key", "sanitize", "_update", "missing_keys", "available_locales", "merge_dict", "delete_empty"] + dir(Box)
    "keys that cannot be used as var names as they are protected for methods"

    def __init__(self, json_folder, target=None, default="en"):

        # the name of the 5 variables that cannot be used as init keys
        FORBIDDEN_KEYS = ["_folder", "_default", "_target", "_targeted", "_match"]

        # init the box with the folder
        folder = Path(json_folder)

        # reading the default dict
        default_dict = self.merge_dict(folder / default)

        # create a dictionary in the target language
        targeted, target = self.find_target(folder, target)
        target = target or default
        target_dict = self.merge_dict(folder / target)

        # evaluate the matching of requested and obtained values
        match = targeted == target

        # create the composite dictionary
        ms_dict = self._update(default_dict, target_dict)

        # check if forbidden keys are being used, this will raise an error if any
        [self.search_key(ms_dict, k) for k in FORBIDDEN_KEYS]

        # unpack the dict as encaplsulated Boxes
        ms_json = json.dumps(ms_dict)
        ms_boxes = json.loads(ms_json, object_hook=lambda d: Box(**d, frozen_box=True))

        private_keys = {"_folder": str(folder),"_default": default,"_targeted": targeted,"_target": target,"_match": match}
        super().__init__(dict(**private_keys, **ms_boxes), frozen_box=True)

There are several points within the box itself it may have to recreate itself and pass down the current set of settings, so you will always have to accept **kwargs and pass them through the super call.

I tried the following:
def __init__(self, json_folder, *args, target=None, default="en", **kwargs):
    # do stuff
    super().__init__(*args, **private_keys, **ms_boxes, frozen_box=kwargs.pop("frozen_box", True), **kwargs)

and now I have a Path error:

TypeError: expected str, bytes or os.PathLike object, not Box

Digging into it, it seems that init is launched twice and the second time json_folderargument becomes a Box


WIP: CleanUp JavaScript for satisfying linters

Cleaning up JavaScript code under models/tools/xmi2yang/ and its sub-directories according to the linting results from 	#12 ...
This PR also contains the commit from #12 and should therefore only be merged after the latter!

The current linting result can be seen here:
https://travis-ci.org/OpenNetworkingFoundation/CENTENNIAL/jobs/202737519
It is currently only based on ESLint, with some disabled rules:

no-undef and no-console are just inappropriate
no-redeclare just causes too much violations and is... hmm... let's say not that important for now ;)

And only one issue is left... Which is unclear how to solve:
https://github.com/OpenNetworkingFoundation/CENTENNIAL/blob/66a483fb6e675945b94a8e13c718a34d18140724/models/tools/xmi2yang/main.js#L2049
Is that assignment inside the if (...) condition intended? It looks more like it should be a comparison...