RFC: Add initial plugin schema types.

@bgrant0607 @thockin @davidopp
(this is just the beginning ;)

cc @lavalamp

Ref #991, #3201
cc @smarterclayton

This is a different approach than I had in mind. Do we really want to understand the objects of plugins in this much detail? Is it necessary?
I was thinking more along the lines of carving off a URI for apiserver to proxy to the plugin, and provide a general storage point for the plugins to store their data.
Additionally Schema is going to be a super confusing name considering that we have a Schema go type already, but that's a minor point.

This is unreviewable without a design sketch.
What about:

dynamic endpoint registration?
delegation to another server?
reflecting add-on component health in /componentstatuses?
defaulting?
conversion?
validation?
storage via the registry?
...

@bgrant0607 - sounds like something a 'green' would say ;-)

Swagger?

I'm waiting for the doc for further comments.

I'm happy to throw together a design doc if that helps make it reviewable, I'll attach it this evening/tomorrow.
Regarding swagger etc. a bunch of the tooling doesn't handle recursive structs correctly so we need to do some work there.

My initial reaction to this is how I would use this to model objects that are consistent with the current object patterns in Kubernetes.  For example, wont't my config objects have a spec/status like all other objects?  Basically, if we are proposing a model where we express our Schema dynamically, shouldn't we be able to express our own internal objects using the same approach?  We have the goal of making the API server dumb, but I feel like this makes two classes of dumb... dumb (our objects) and dumber (plugin objects).

I think most of the questions you are asking are with regard to implementation
(and some like other kinds of delegation are outside of the scope of this PR)
I'm happy to dump the implementation of all of that stuff into this PR too, but I think it will go faster if we just focus on the API types, without arguing about the implementation.

@derekwaynecarr it's an interesting question (and one that I struggled with myself) but I don't think we can/should impose our Spec/Status style objects onto the world.  If I want to do something else, yet still use the Kubernetes APIServer for namespace/acl/user/etc, I should be able to.
I could imagine introducing two different types of extensible objects:

Kubernetes-aware objects which conform to spec/status etc (not really in this PR)
Opaque objects which are just data blobs (more in line with this PR)

@brendandburns I came at this PR with the mind set of "Why are OpenShift objects not plug-in objects?" in this new world.  Maybe that was the wrong initial approach, but we get great value in conforming to the spec/status approach for objects we build on the system.

@derekwaynecarr I totally agree (and there's nothing preventing you from doing that) but I think this needs to be more general than that, it needs to allow for users to do anything they want.
@lavalamp there is way more value in centralizing it.  For example, you are going to require users to implement compare/swap correctly.  Do you really want a watch to go from the APIServer, into their code, back into the "storage" part of the API server?

Your approach is more like the following to me:
"I want an object that is basically a <KindName>  + <OpaqueFields> that may or may not be in a Namespace?" to hang arbitrary data for my need.
So REST API becomes a collection of subresources like following:
/namespace/x/plugins/pluginA/item1
/namespace/x/plugins/pluginA/item2
/namespace/x/plugins/pluginB/item1

Is there a target consumer that would be driving requirements assuming the OpenShift plug-in objects may be out of scope?

Also the simple "if you implement this, who will use it and why".

how would someone secure this?  How does a generic authorizer impose auth
on this?
prevent a rogue agent from bringing down the master server (limit / quota)

Why would I do this instead of running my own copy of etcd on Kube?
On Jul 23, 2015, at 7:44 PM, Brian Grant<EMAIL_ADDRESS>wrote:
This is unreviewable without a design sketch.
What about:

dynamic endpoint registration?
delegation to another server?
reflecting add-on component health in /componentstatuses?
defaulting?
conversion?
validation?
storage via the registry? ...

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11781#issuecomment-124270385
.

@lavalamp there is way more value in centralizing it. For example, you are going to require users to implement compare/swap correctly.

I think that part can be delegated to apiserver.

Do you really want a watch to go from the APIServer, into their code, back into the "storage" part of the API server?

If the alternative is turing-complete API types, then absolutely definitely yes...
I mean I can imagine a compromise thing, where apiserver takes arbitrary blobs and just calls hooks via http before servicing api calls. That way you'd just call to verify that a watch was OK instead of streaming everything through three hops. We'd provide a starter package (maybe refactor replication controller) so that people have a clear example of how to implement it.

We're going to need to split spec and status in etcd in order to reduce false conflicts: #8625

A requirement is that the mechanism should be powerful enough for us to convert ReplicationController to a plugin. If it's not, it's not good enough.

Openshift objects should not be out of scope. I'd like to decompose several pieces of Openshift functionality and offer them as add-ons/plugins.

@smarterclayton there is no difference between these API objects and any other API objects.
In terms of Authorization, it will use namespace/path based ACL-ing just like everything else.
In terms of DOS, it's no different (in fact it's better, because unlike Pods, nothing on the master actually starts to build anything)
In terms of "why wouldn't I just run my own etcd?" there is lots that you get from the API server including:

JSON encoding and validation
Authorization and ACLs
Watch
REST API types

I think that the presence of the CustomObjectData is confusing people.  CustomObjectData isn't the end user's object, it is just necessary for us to store things generically into etcd and use Codec to do it.

I updated this with a design sketch that (hopefully) clarifies things.  Let's move the discussion to that doc.

I did look at Swagger, it is way more complicated than what I think we need.  We can specify a single set of paths for each custom object.  We don't need all of the API meta information, as it is constant for all custom types.
I could see an alternate method of extension that took a swagger spec and simply delegated to a Pod, but I think that is complimentary to this approach.
The main goal here is just "store my stuff for me and make it available"
It is intended to be cheap, lightweight, and easy to grok, but yet still providing useful functionality.

fwiw, I think that you can implement ReplicationController with the current scheme (it's a little bit uglier, but it's possible)
And this is just a starting point.  I think we will want to add "native" objects that conform to the metadata/spec/status format as well, but we shouldn't block getting started on designing the perfect thing, assuming that we think that there is a path forward to the desired state, and I think that there is a path here:
introduce an additional fields on Version:
type Version struct {
   ...
   // "native" objects are required to specify SpecSchema and StatusSchema, and have a nil Schema
   SpecSchema *Schema
   StatusSchema *Schema

   // "opaque" objects are required to specify Schema and have nil SpecSchema and StatusSchema
   Schema *Schema
}

I've written up an alternative design in #11823.

This feels really quarter-baked.  No sub-resources.  No POST.  No naming/metadata.  No spec/status.  No defaults.  No validation.  No conversion logic.  These are the things that make the apiserver a complete solution and give consistency.  You say you don't think we should impose conventions, but I sort of do.
I agree strongly with Derek - we should be able to implement our own objects in this, and I don't see it happening as is.  This feels more like the config blobs than API extensions.  Why not just store opaque JSON - what are we doing with the schema-expanded fields?

We should not be inventing a new schema description language. Use swagger, or nothing.

We should be imposing conventions. For starters, all API objects would need to adhere to our metadata conventions -- at minimum, TypeMeta, so that kubectl will be able to work with the objects. Otherwise there's not much point.

If we want something done super-quickly, I'd rather just finish the API groups and add a mechanism for enabling/disabling them, similar to how we gate deprecated and in-progress APIs.

In terms of letting people prototype, if we had even a single
'experimental' apigroup and code-level (compiled-in) plugins, we could at
least unblock while we do the right thing for out-of-process plugins.
On Jul 24, 2015 9:06 PM, "Brian Grant"<EMAIL_ADDRESS>wrote:

If we want something done super-quickly, I'd rather just finish the API
groups and add a mechanism for enabling/disabling them, similar to how we
gate deprecated and in-progress APIs.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11781#issuecomment-124793957
.

Exactly.
On Jul 25, 2015 8:39 AM, "thockin-cc"<EMAIL_ADDRESS>wrote:

In terms of letting people prototype, if we had even a single
'experimental' apigroup and code-level (compiled-in) plugins, we could at
least unblock while we do the right thing for out-of-process plugins.
On Jul 24, 2015 9:06 PM, "Brian Grant"<EMAIL_ADDRESS>wrote:

If we want something done super-quickly, I'd rather just finish the API
groups and add a mechanism for enabling/disabling them, similar to how we
gate deprecated and in-progress APIs.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/pull/11781#issuecomment-124793957
.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11781#issuecomment-124853908
.

Ok, this has been revised to reflect further discussions.  Specifically:

Schema is now ThirdPartyObject
Kubernetes metadata is now required for all ThirdPartyObject s
SchemaSpec, Fields, etc. have been dropped from the API

I will also block this PR (for now) on an initial experimental api group and add it in there (when it exists)
Please take another look and validate that these objects and usage look ok.

Since this is namespaced only for now, can you state clearly that if you delete the namespace, it will delete the data?
I imagine there is a hive of plug-in objects floating around in your head that you want to use this for, but I worry we will start to use this and get bad lifecycle consequences, particularly around object relationships (between core objects and plug-in objects) or plug-in objects that need to implement cascading behavior.
I guess I stand by my original statement that this design lacks an identified consumer driving requirements.

One benefit of the field design was that you could potentially make use of fieldSelectors when LIST/WATCH to target your data.

@derekwaynecarr This is the default behavior in general, but I added a note to this effect.]
Regarding a use case, I have promised a complete implementation of a Cron service using this infrastructure prior to committing, and I will produce that.  Hopefully that will show you the set of use cases this addresses.
(fwiw, I acknowledge that this is only half the solution, the HTTP hooks that were described in #11823 are also an important part of the solution, but I think they are orthogonal to easy-to-use storage)

As I commented on #11823:
This is nowhere near rich enough for any any existing or proposed first-class APIs: ReplicationController, upstreamed Openshift resources, Deployment, Daemon, Job, ScheduledJob, ConfigData, Autoscaler, PodStats, NodeStats, ... It doesn't support features like subresources, swagger, strategic merge patch for declarative configuration, exporting clean configs, validation, conversion, custom create or update logic, etc. etc. Nor will it support many things we want to do in the future, in #8190, such as splitting spec and status into separate objects in etcd, or preconditions on multiple objects in etcd. For first-class API extensions, I'd like to see us facilitate apiserver federation, incorporation of apiserver into other projects, addition of new types to apiserver, and maybe an apiserver-backed registry implementation.
The approach in this PR is intended for prototyping and 2nd-class APIs.
While we might want to support hooks at various extension points, I think building a full-blown API using them is likely to be more complex than it's worth.

Comments (mostly) addressed.  Please re-check.
Thanks!
--brendan

@bgrant0607 can I get a re-review here?
Thanks

Rebased.  I see that the experimental subgroup is in.  I will work to integrate under that.  In the meantime a re-review + approve of the API stuff in parallel would be useful.
Thanks
--brendan

Lingering issues with the experimental API include autogeneration of conversions and deepcopies, and client support. We expect those issues to be resolved in the next couple days, so I think you can start moving this to the experimental API.

Or if you want to merge this first, you can add it to ignoredKinds so that it won't be exposed as a v1 API.

Comments addressed, I added the type to ignoredKinds, I will work on adding it to the experimental API in a different PR.

@bgrant0607 friendly monday ping on this.
thanks!
--brendan

@bgrant0607 Comments addressed, please re-check.
Thanks
--brendan

Comments addressed, please re-check.

@bgrant0607 Comments addressed, please re-check.
Thanks!
--brendan

fwiw, Shippable is a flake, I hit it again.

Now passing everything...

Thanks.
LGTM

Thanks for your patience!


chore(RingTheory): delete useless lemma

As discussed in https://github.com/leanprover-community/mathlib4/pull/11790 for the case of Lie derivations, it seems that this map_sum lemma is not useful since we can use the generic version.

bors merge


MS6: Write milestones document about validation tools

Description of the issue
As part of the reporting for MICROBE WP3, we need to write a milestone progress report document for MS6: Validation tools for assessing compliance with standards for microbiome biobanking implemented.
We had a brief chat on 13th June where we divided and briefly discussed the sections on this document

Check up deadline: 27th June 2022
Hard deadline: EO July (Prob Last week)

Meeting on 27th June


[BugFix] stop be without -g parameter

kill be as quick as possible to restart the pod

What type of PR is this:

[X] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes:

Fixes #
Problem Summary(Required):

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[X] I have checked the version labels which the pr will be auto backported to target branch

[X] 3.0
[X] 2.5
[ ] 2.4
[ ] 2.3

@kevincai, in auto-scaling clusters, the addition and removal of BE happens frequently. To ensure successful execution of in-flight queries, a graceful exit is utilized.
So I think we should keep the graceful exit here.

this pr is to remove graceful shutdown for be, not cn. cn graceful shutdown is still there with no change.

and right now the be graceful shutdown doesn't work at all. need to kill -9 to force kill be process.

and right now the be graceful shutdown doesn't work at all. need to kill -9 to force kill be process.

It should work even for Backend, @chaoyli can take a look.

we can add this back when it works for be.

@Mergifyio backport branch-3.0

@Mergifyio backport branch-2.5


⚠ Bofrost.at has degraded performance

In bdc0978, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1127 ms

Resolved: Bofrost.at performance has improved in 230f71b.


[#86] Fix incompatibility with PostgreSQL 16.0

This patch fixes outdated migration V3 which set a column to default to 0::TEXT::xid8 which became invalid syntax in Postgres 16. The relevant column has since been updated to a BIGINT and the default is set to 0 in migration V4.
Selected fix is to replace the invalid syntax in migration V3 with 0 which seems to work fine with xid8 columns as well. Tested in Postgres 13.12 and 16.0.
Fixes #86.

Maybe this would be a good time to add tests for different versions of pg

Maybe also a good time then to migrate to github actions?


Single command is executing on devices associated with different users.

Hi,
I am facing issues after following below steps:

Login with user rick. Add devices
Login with user summer (in a separate browser, I am using incognito mode of Chrome). Add devices
Now send the command from action console. This command will change the state of devices on both users. However I have linked my account with user rick only so expecting the devices associated with rick to be changed only.

That could be a bug in the sample. I've usually used rick as a user.

The sample has now been significantly updated. Devices should now be linked to a singular user.


PR:Fix Refund query with http GET

退款查询接口要求GET方法：查询单笔退款API
see PR：#266

Thx, PR has been merged, I will make a release version later.

pls check v3.0.13


Allow 'sudo' usage in buildroot.sh

If 'sudo' is configured properly it can be used for the various steps
in buildroot.sh which require root privileges. This avoids the need to
to run the entire script with such privileges. Users can enable this
mode by setting use_sudo=1 in buildroot.conf.
Signed-off-by: Kevin P. Fleming<EMAIL_ADDRESS>

Could you resolve SC2115?


Powertrack backfill

Changes make it possible to create a PowerTrack v2 stream URI with the backfillMinutes parameter described here: http://support.gnip.com/apis/powertrack2.0/transition.html#BackfillBehavior

Merged at https://github.com/zauberlabs/gnip4j/commit/8c56828942ba8646bdeb9dac0f8a845d9a05e20a
I decided to fully expose the parameter in the interface


Install instructions are actually build instructions

You might want to consider providing a pre-compiled binaries via GitHub releases.

Thank you @eisraeli for creating this issue.
We will provide pre-compiled binaries via GitHub releases as soon as we have some process for standard semver releases. KubeSaw doesn't have such a process yet, but it is being planned (including the pre-compiled) for the next year.


feat: add support for viewing read-only channels where appropriate

added option to endpoint to pass on includeReadOnly parameter (and removed options that don't exist)
added --include-read-only (-I) option to edge:channels command to include accepted/read-only/subscribed channels in the list
made use of new endpoint parameter for edge:channels:enroll, edge:channels:unenroll and edge:channels:drivers commands where including read-only channels makes sense
removed duplicate example from edge:drivers:package command

Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[X] I have read the CONTRIBUTING document
[X] My code follows the code style of this project (npm run lint produces no warnings/errors)
[X] Any required documentation has been added
[ ] I have added tests to cover my changes

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Not Working on chrome but working on android

Its not working, and its only displaying 'Mmm' at times when I use chrome. When using android its working well.

Works fine on Chrome for me from Mac, Windows, and Android.

See #22


fix file name when using jQuery plugin

Thanks!  @domchristie feel free to merge changes in whenever you'd like


Refinement: setting batch_size for different models

Since Google's model, OpenAI's model, and Azure OpenAI's model don't support batching locally, we will instead use num_thread to "fake batch" the data.

Will format the code shortly

Please reformat your code to resolve build failure https://github.com/CambioML/uniflow-llm-based-pdf-extraction-text-cleaning-data-clustering/actions/runs/8164445774/job/22319716558?pr=212

Could you please also check all notebook regarding whether you need to make corresponding changes as well as cookbook repo? Get @jojortz to review the cookbook repo.

Could you please also check all notebook regarding whether you need to make corresponding changes as well as cookbook repo? Get @jojortz to review the cookbook repo.

Noted


Refactor poolers

Just refactoring (copy-pasting) of methods from MultiScaleRoIAlign in order to pre related to the following PR https://github.com/pytorch/vision/pull/4810/files
This one should be merged first.
cc @datumbox

after checking I noticed that the methods I moved around in the other PR dont really need to be moved so I will merge this one as it


Migrate Thermostat and HVAC component to climate component

Description:
This is a work in progress PR to merge the HVAC and Thermostat component into a new Climate component.
We want to migrate all platforms to a new component that is called climate.
It takes all the functionallity of the existing HVAC comonent.
The set_hvac_mode used in thermostat component equals to the set_operation_mode.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#
Example entry for configuration.yaml (if applicable):
climate:

Checklist:
Platforms for migration:

[x] demo
[x] ecobee
[x] eq3bsmart
[x] heat_control
[x] heatmiser
[x] homematic
[x] honeywell
[x] knx
[x] nest
[x] proliphix
[x] radiotherm
[x] zwave

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If code communicates with devices, web services, or a:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

You missed knx thermostat for coverage and could you copy the generic thermostat tests from the heat_control ?

Wow, I can't believe you made so much progress. That's amazing!

Very cool work. After you finish that, I'll improve the homematic component to support more of this new functionality 👍
You will not add a schema for you services?

Anyone with understanding of schemas, could you please have a look at the and see if its done right?

 I don't test it. Its not very hard to use...

I think that this is ready to be merged 🐬

We can merge this before the frontend is done btw.

I think I'm done with this..... So if you don't see any problems, then :dolphin:

Now I'm done :sweat_smile:

Awesome !


WIP: client bits

Testing running: gcloud config unset container/use_client_certificate

@douglas-reid: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
af41a9f922c574e4b7ceb70c5d4a40b88b7b8bf0
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@douglas-reid: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
af41a9f922c574e4b7ceb70c5d4a40b88b7b8bf0
link
/test istio-unit-tests

prow/istio-presubmit.sh
af41a9f922c574e4b7ceb70c5d4a40b88b7b8bf0
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Plugin config widgets don't resize when their contents change

If the structure inside a plugin's config widget changes and causes the size of the widget to change as a result, the widget in the plugin list does not actually resize, which causes some odd rendering behavior.  Hiding and showing the plugin will cause it to recalculate its size, but it would be nice if it happened automatically.

Here's an example of what the PointCloud2 plugin currently looks like after it's hidden a few of its internal widgets.


Add Cog Support

Adding cog to the project could make it easy to utilize imaginAIry on platforms such as replicate.com or simplify deploying imaginAIry to your own ML infrastructure.
Willing to give it a go on my end, when I have time and hopefully can get access to pushing to replicate soon.
A simple POC with command line arguments as input would be the easiest path forward imo but open to discuss.

I'm not familiar with cog so my initial reaction is "i dont know".
I have deployed imaginairy in containers a few times this is the setup script I'm using currently:
  apt-get update
  apt-get install -y libgl1 libglib2.0-0

  wget https://developer.download.nvidia.com/compute/cuda/repos/debian11/x86_64/cuda-keyring_1.0-1_all.deb
  dpkg -i cuda-keyring_1.0-1_all.deb
  apt-get update
  apt-get install -y cuda=11.5.1-1

  pip install --upgrade pip setuptools wheel pip-tools;

  cat requirements-dev.txt | grep -v "^torch==" | grep -v "^torchvision==" > requirements-filtered.txt;
  cat testing_support/requirements-torch.txt >> requirements-filtered.txt
  pip-sync requirements-filtered.txt;

  pip install --no-deps -e .;
  imagine pizza --steps 2;
  touch /root/.initial-setup-done;

good thankyou


Phase 3: Latent Bugs

any lingering bugs, drop em here..

Per user feedback: Not all challenge pages have inline links to OWASP articles. Users can always select the [help] modal dialog so.. this might be a no-fix.

OPEN: [02:/ctf/dirs.js:*] Re-write Directory Traversal to make more sense; Replace 'up and down' verbiage; Text cleanup (it's too "busy"

OPEN: [03:/ctf/dirs.js:Ipad-Safari] Mobile Safari on IOS does not render faux browser

OPEN: [04:/ctf/sqli.js:*] Missing CTF icon flag at top of page

OPEN: [02:/ctf/lfi.js:*] Typo:


time to fix input error handling

Bad pedigree files gives:

scala.MatchError: [Ljava.lang.String;@eb1d475 (of class [Ljava.lang.String;)

:-(

I think this has largely been resolved.


Implement MergeRequestCheck on the FileHooks plugin

Hi, I have implemented a MergeRequestCheck - The original plugin did not allow a hook on a merge request from a repository without hook settings to one with.
I would like to create a pull request with my changes, but do not have permissions. How can I do that?
Branch name- MergeRequestCheck

Hi,
please use the usual Github flow and create a clone of my repo, make your changes on a new branch on the fork repo and when done please create a PR between the branch on the fork repo and master of this repo.

Sorry about that, it's the first time I'm using Github, I've created a pull request

Implemented and released for File Name Hook in version 2.4.0. File Size Hook is open.

Thank you!


[TimeSeries] When the is editable bit is set the TimeSeries card isn't showing fake data

Describe the bug
when the isEditable bit is set, the TimeSeries card isn't showing fake data
To Reproduce
Steps to reproduce the behavior:
View the timeseries isEditable story, that should show fake data in the timeseries card

:tada: This issue has been resolved in version 1.98.7 :tada:
The release is available on:

npm package (@release-1.x dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

This was supposed to close with the above referenced PR.

:tada: This issue has been resolved in version 2.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


First pass at removing User model requirement.

New option CUSTOMER_REF_MODEL lets you specify any arbitrary model to attach a Customer model to, not just the User model.

Sorry, didn't mean to open this. It's still very experimental!

Coverage decreased (-0.02%) to 81.53% when pulling 4de4289f3b09f76607e98031da5a799e1005025f on ROIKOI:remove-user-model-requirement into 4c451b62b8169a67e9e4a17af7bc5311e43ca58e on pinax:master.


Install via NPM

Would be nice with instructions on how to install this via NPM, to avoid having to make an HTTP request to pull the file for every page load (i.e. /latest.js).
This will also help with Adblockers, since the code is instead bundled inside the static HTML/CSS/JS for the website.
Is this possible today? And if so, maybe add some instructions in this repo or in your docs (I've tried to find it, but no luck, but maybe I'm blind 😄)

You mean server side?

Depends on what you mean by server-side, but I'm thinking of build-time for popular Single Page Applications (SPAs) such as React, Vue and Static Site Generators such as Astro, Hugo and Gatsby.
For all of them, being able to bundle the simple analytics code among all other JS code (instead of fetching it on every page load) would be a win.

Ah, I see. Bundling with the rest of the bundle. It's not on our roadmap, but always happy to accept pull requests.


[alts] Fix memory leak in alts_crypter_create_common

Fix https://github.com/grpc/grpc/issues/37692

Hi Matthew, since this touches alts can someone from the security team take a look? Thanks!

Thanks for putting together this fix @yijiem! Can we add a test that would have caught this leak?


Reduce log spam from h2 and tower

After adding instrumentation, h2 and tower debug logs were spamming the logs a
bit, as they're used by Rocket and libp2p respectively.
Setting them to INFO should reduce that spam.

merging as it's a trivial change.
bors r+

While this does work for logs, it is important to note that this still results in traces which are somewhat irrelevant, since base_directives is only applied to fmt_layer, and not tracer or the Registry as a whole. I would suggest a followup PR to apply a different set of base directives to the tracer, since more detail is wanted than in logs, given that traces are inherently more readable (IMO) since they can be collapsed, but still not every h2 poll or send_data.

a bit 😅 We produced 100gig of logs in 12h


Rename cmd/manager to cmd/forklift-controller

Codecov Report
Base: 34.12% // Head: 34.12% // No change to project coverage :thumbsup:

Coverage data is based on head (ec773a3) compared to base (691f6b7).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #70   +/-   ##
=======================================
  Coverage   34.12%   34.12%
=======================================
  Files          42       42
  Lines        8036     8036
=======================================
  Hits         2742     2742
  Misses       5077     5077
  Partials      217      217

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Allow no message dispatched

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-9.07%) to 17.241%

Totals

Change from base Build<PHONE_NUMBER>:
-9.07%

Covered Lines:
20

Relevant Lines:
116

💛  - Coveralls


fix: update scaleway ui v0.178.3

Summary
Type

Chore

Summarise concisely:
What is expected?
Scaleway UI update

Codecov Report

Merging #447 (a6054ca) into main (cb3d7a7) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #447   +/-   ##
=======================================
  Coverage   92.25%   92.25%
=======================================
  Files          26       26
  Lines         310      310
  Branches       37       37
=======================================
  Hits          286      286
  Misses         13       13
  Partials       11       11

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 365e4b4...a6054ca. Read the comment docs.


Retrieving metadata doesnt work for me

Import works normal, package is installed correctly, but landsat8.metadata('LC08_L1TP_016037_20170813_20170814_01_RT', pmin=5, pmax=95) gives me the following error.
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/cachetools/func.py", line 58, in wrapper
v = func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/rio_tiler/landsat8.py", line 71, in metadata
meta_data = utils.landsat_get_mtl(sceneid).get('L1_METADATA_FILE')
File "/usr/local/lib/python2.7/dist-packages/rio_tiler/utils.py", line 217, in landsat_get_mtl
raise Exception('Could not retrieve {} metadata'.format(sceneid))
Exception: Could not retrieve LC08_L1TP_016037_20170813_20170814_01_RT metadata
I am using Linux Ubuntu, Python 2.7.12.

Thanks @g07kore
I found the bug and going to fix it
I'll release a new version soon with the fix.


document --full-trace option

(Thank @twada for pointing it out at #1696)

This seems to have been documented on the main page. Does more need to be talked about?

Seems documented to me?


Mitigate accidental form submission on desktop browsers

When folks use good old fashioned keyboards, we have reports that they will sometimes hit Enter and accidentally submit an entry prematurely. We should probably prevent Enter from triggering the default form action unless the Submit button has focus.

Dupe of #56 from way back 😬


istio: Support bpf lookups, update to 1.1.7

Update Istio to 1.1.7 and allow Istio sidecar proxies to make bpf map
lookups. This requires the proxy pod to run with SYS_ADMIN in addition
to NET_ADMIN capability.
NOTE: This PR builds on top of #8113 and needs to be rebased once it merges.
Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>Istio support is updated to version 1.1.7.

This change is

test-me-please

Fixed minor doc format and spelling issues.

test-docs

test-me-please

Coverage increased (+0.01%) to 41.931% when pulling 3a534fca09f78f36a17db2488b7a860fbbeed7e6 on pr/jrajahalme/istio-update-to-1.1.7 into 8553ac359bfd5551f9a1f32a19ee4853a9623bfb on master.

test-me-please

rebased to the master with merged "parent" PRs.

test-docs-please

Hit #8175, will re-run CI.
https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/12691/

test-me-please

CI fail that looks like #7546, but for a different test (https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/12707/testReport/junit/Suite-k8s-1/14/K8sDatapathConfig_Transparent_encryption_DirectRouting_Check_connectivity_with_automatic_direct_nodes_routes/)

test-me-please

test-docs-please

test-me-please

test-docs-please

I've addressed the change requests by @aanm, this should be ready to merge.


bluetooth: controller: Fix for coverity CID 203524

Signed-off-by: Morten Priess<EMAIL_ADDRESS>

Fix for coverity issue #18382

@cvinayak pls, revisit once more


fix: cleanup Glance when user navigates away from list or preview

Prior to this commit it was easy ot break Glance's UI.
If you navigated out of the list or preview the Glance UI would stick around until you either close the buffer or issue another Glance preview.
Even worse, if you accidentally navigated to a new buffer while inside the list or preview window the UI breaks completely and issuing a new Glance preview does not fix things.
To fix these issues, create a new 'cleanup' autocommand which runs exactly once when the user navigates away from either the preview or list windows.
This protects against both outlined issues.

Thank you, the idea was to use virtual lines to fill the space where glance is rendered so the preview window doesn't obstruct the code underneath and gives the ability to navigate the parent window, but virtual lines capabilities were limited at the time.

Thank you, the idea was to use virtual lines to fill the space where glance is rendered so the preview window doesn't obstruct the code underneath and gives the ability to navigate the parent window, but virtual lines capabilities were limited at the time.

I was always curious if that would work in a plugin like this. It would look very much like VScode. Its a good idea, shame it doesn't pan out in practice :(.


[WIP] Show channel funding TX expiry in listchannels

Resolves #7434
This is still a work in progress as it's not fully tested. Putting this up early for feedback. Feel free to be brutally honest. I'm new to LND and Go Lang, so still stumbling my way around.
This adds the recommended field funding_expiry_blocks to the Channel message and then computes the value based on whether the channel IsPending, and then uses the broadcast height of the funding transaction, the height of GetBestBlock, and MaxWaitNumBlocksFundingConf.
At the moment, this is computed in rpcserver.createRPCOpenChannel as this seemed to be where the lnrpc.Channel is created from a channeldb.OpenChannel. I'm a little suspicious whether it's okay to be calling r.server.cc.ChainIO.GetBestBlock on every channel, so if that's not right, please let me know.
Also not clear if this should be on lncli listchannels or on lncli pendingchannels. Intuitively, once the funding transaction is confirmed this field doesn't provide any information.
Manual Testing:

Created a simnet between alice and bob and did lncli openchannel.
After generating 3 blocks on btcd, I could verify the funding_expiry_blocks using lncli listchannels.
However, the channel does not show up at all in lncli listchannels until at least 3 blocks are generated. As such, I could not see a value other than -1 for funding_expiry_blocks without hacking up the logic to always compute the value.
On the other hand, before 3 blocks are generated, the pending channel does show up using lncli pendingchannels, but the funding_expiry_blocks is not part of the response :(

Please let me know if the approach here is correct.
Next steps:

Write tests. I'm looking at ht.QueryChannelByChanPoint and either directly adding to testListChannels or writing an independent test.

seems like it should be part of pending channels rather than active channels

Yeah, sorry, my example in the issue referenced the wrong proto message. A channel only moves to listchannels once it is confirmed and the count down isn't needed anymore. So pending channels is correct.

Abandoning in favor of PR #7480


fix(deps): update terraform terraform-ibm-modules/secrets-manager/ibm to v1.18.6

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/secrets-manager/ibm (source)
module
patch
1.18.5 -> 1.18.6

Release Notes

terraform-ibm-modules/terraform-ibm-secrets-manager (terraform-ibm-modules/secrets-manager/ibm)
v1.18.6
Compare Source
Bug Fixes

deps: update terraform terraform-ibm-modules/event-notifications/ibm to v1.10.17 (#209) (e71a27f)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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

GitHub release
v8.11.14

Your semantic-release bot :package::rocket:


Fix hipArray test (post PR 1399)

This PR reverts changes only in hipArray test.

This test fails on Vega 20 GPU #1511 fixes the issue.

Closing this since the test is disabled currently and will be rewritten before enabling it again.


add support for rsa createKey/encrypy/decrypt with sgx-ssl api

it can create rsa key and length is 2048 or 3072
padding mode supports RSA_PKCS1_PADDING and RSA_PKCS1_OAEP_PADDING
add test case for rsa_2048/3072_encrypt/decrypt
test: passed the unit test
Signed-off-by: wanghaiheng<EMAIL_ADDRESS>

Suggest referring to the code:
https://github.com/intel/ehsm/blob/main/core/Enclave/enclave_hsm.cpp#L478 ~ L795
and define a reasonable rsa_cmk_blob { }


Configuring event subscriptions for multiple events

I tried to use the OPC publisher to subscribe to multiple events using the Simple event filter. However it is not clear from the documentation how the configuration has to look like for multiple events.
I tried different ways, for example using multiple OPCNodes:
[
    {
        "EndpointUrl": "opc.tcp://testserver:62563/Quickstarts/SimpleEventsServer",
        "OpcNodes": [
            {
                "Id": "i=2253",
                "DisplayName": " Event1 ",
                "EventFilter": {
                    "TypeDefinitionId": " ns=2;i=1000"
                }
            },
            {
                "Id": "i=2253",
                "DisplayName": " Event2",
                "EventFilter": {
                    "TypeDefinitionId": " ns=2;i=1001"
                }
            }

        ]
    }
]

However none worked. With the example above, I always only got the last defined event.
Please update the documentation with an example for multiple event subscription and/or if the config above should work investigate further, why it doesn't.

The issue is fixed in the latest preview release.  The image is available at mcr.microsoft.com/iotedge/opc-publisher:2.9.3-preview2.  Please let me know whether this does not fix your issue.


retryPolicy is not working

What version of gRPC and what language are you using?
1.50.1, c++
What operating system (Linux, Windows,...) and version?
Linux Ubuntu 22.04.3
What runtime / compiler are you using (e.g. python version or version of gcc)
gcc 11.4.0
What did you do?
Used triton's grpc api with service config file triton_service_config.json:
{
    "methodConfig": [
        {
            "name": [
                {
                    "service": "inference.GRPCInferenceService",
                    "method": "ModelInfer"
                }
            ],
            "waitForReady": false,
            "retryPolicy": {
                "maxAttempts": 5,
                "initialBackoff": "0.1s",
                "maxBackoff": "60s",
                "backoffMultiplier": 10.0,
                "retryableStatusCodes": [
                    "UNAVAILABLE"
                ]
            }
        }
    ]
}

    std::ifstream service_config_file("triton_service_config.json", std::ios::in);
    std::string service_config_json(std::istreambuf_iterator<char>(service_config_file),
                                    {});
    grpc::ChannelArguments channel_arguments;
    channel_arguments.SetServiceConfigJSON(service_config_json);
    auto channel = grpc::CreateCustomChannel(
        "<IP_ADDRESS>:8001", grpc::InsecureChannelCredentials(), channel_arguments);
    stub = std::make_unique<inference::GRPCInferenceService::Stub>(channel);

What did you expect to see?
Request should return error after retrying 5 times, which should take about 70 seconds.
What did you see instead?
Request returns error immediately.
status is grpc::UNAVAILABLE.
I made sure rerty is enabled by breaking in ClientChannel::UpdateServiceConfigInDataPlaneLocked and seeing enable_retries is true.
I made sure the config json is correct by noticing that changing waitForReady has affect.

Please run with the following env vars set and share the resulting log:
GRPC_VERBOSITY=DEBUG
GRPC_TRACE=client_channel,client_channel_call,client_channel_lb_call,retry

Can't reproduce, It suddenly works 😅

I'm seeing the same issue with the Go client. I've been tweaking the methodConfig every which way I can think of, and even with the following...
	serviceConfig = `{
		"loadBalancingConfig": [ { "round_robin": {} } ],
		"methodConfig": [{
			"name": [{"service": "service.proto.Service"}],
			"waitForReady": true,
			"timeout": "20s",
			"retryPolicy": {
				"MaxAttempts": 100,
				"InitialBackoff": "1s",
				"MaxBackoff": "20s",
				"BackoffMultiplier": 2.0,
				"RetryableStatusCodes": [ "UNAVAILABLE", "RESOURCE_EXHAUSTED", "UNKNOWN" ]
			}
		}]
	}`

... I can see it try a couple times but it never seems to match the configured number of attempts. I've tried it with and without the timeout and waitForReady configs. It just seems entirely inconsistent.
I've used the env vars:
GRPC_GO_LOG_VERBOSITY_LEVEL=99
GRPC_GO_LOG_SEVERITY_LEVEL=info

For issues with the go client, please file an issue in the grpc/grpc-go repo.

Cheers @markdroth
https://github.com/grpc/grpc-go/issues/7514
Opinion on the Gitter chat is that the C client is doing the wrong thing and not the Go client.

From your description in grpc/grpc-go#7514, it seems like Go is behaving wrong.  If you have reason to believe otherwise, please provide details.
In any case, this discussion doesn't seem to have anything to do with this old issue.  If you do think there's a bug in C-core, please file a separate issue for it.  Thanks!


Rewrite to the new, private API

With the new private API, all the IIFEs are unnecessary since we can just pass an object to the styled() calls. This commit updates the plugin and the tests to reflect the new result. Need to wait for styled-components/styled-components#227 (which introduces the new API) to be merged before releasing.

Please review the code @vdanchenkov, I'm not very familiar with writing babel plugins, so if you see things that could be done easier please let me know!
@geelen please review the result of the conversion in the after.js files of the fixtures!

I've been thinking of similar change, but I thought of less intrusive conversion of styled.div to styled('div', {displayName, identifier}) It would make plugin backward compatible with older styled components versions meaning it would not break them. Not sure if it's important.

I don't think that's a concern, since we can just publish a new major version with a peerDep to the new styled-components version that supports it. I don't remember why we decided to not do it that way though, but now it doesn't really matter and I don't want to rewrite it 😉


template file corrected

your template file was not following the folder structure of the project.

your template file was not following the folder structure of the project.

from pathlib import Path
import os
import logging
Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(name)
List of files to create
list_of_files = [
".github/workflows/.gitkeep",
"src/init.py",
"src/components/init.py",
"src/components/data_ingestion.py",
"src/components/data_transformation.py",
"src/components/model_trainer.py",
"src/components/model_evaluation.py",
"src/pipeline/init.py",
"src/pipeline/training_pipeline.py",
"src/pipeline/prediction_pipeline.py",
"src/utils/init.py",
"src/utils/utils.py",
"src/logger/logging.py",
"src/exception/exception.py",
"tests/unit/init.py",
"tests/integration/init.py",
"init_setup.sh",
"requirements.txt",
"requirements_dev.txt",
"setup.py",
"setup.cfg",
"pyproject.toml",
"tox.ini",
"experiment/experiments.ipynb",
]
Loop through the list of files and create them
for filepath in list_of_files:
filepath = Path(filepath)
filedir = filepath.parent
# Create directory if it doesn't exist
if filedir != "":
    os.makedirs(filedir, exist_ok=True)
    logger.info(f"Created directory: {filedir}")

# Create empty file if it doesn't exist or is empty
if (not filepath.exists()) or (os.path.getsize(filepath) == 0):
    with open(filepath, "w") as f:
        pass  # create an empty file


missing deps on cli

Current:
when installing a clone of the repo and issuing:
python setup.py install

running the cli fails with a missing dependency error:
File "/home/jasonjason/miniconda3/envs/ystafdb/lib/python3.8/site-packages/ystafdb-0.4-py3.8.egg/ystafdb/graph_common.py", line 3, in <module>
ModuleNotFoundError: No module named 'rdflib'

The following dependencies are also missing:

rdflib
pandas

This has been fixed by
https://github.com/BONSAMURAIS/ystafdb/commit/e22099cbbbda2d559fab6a7d70c081f505df1316


Missing requirement: ext-mbstring

I'm on a fresh vm and I didn't install the mbstring extension yet.
Call to undefined function Intervention\Image\mb_convert_case() in [...]/vendor/intervention/image/src/Intervention/Image/AbstractDriver.php:105

The dependency was introduced by PR #837 https://github.com/Intervention/image/commit/e82d274f786e3d4b866a59b173f42e716f0783eb#diff-91971e0c7772a60fab6fbe264d649d99
I think there are 3 options (all of which I'm more than willing to send a PR for :))

add ext-mbstring as a requirement in composer.json
check if mbstring is available before using the functions. If it's not available use standard php functions instead
remove the code that causes the problem (= revert the PR essentially)

I can't decide between these options either :)
Maybe I'd rule out option 2, as it could introduce some surprises when changing environment.

I added a commit in my PR that may interest you. I'm using Symfony's mbstring polyfill. This way we have the best of options 1 and 2 combined :)
Also, maybe the mbstring extension is not as widespread as I though, and requiring to recompile the server might irritate some people…

I decided to add mbstring as dependency for the next release of Version 3.


Create FunctionConfig for Lake-of-Segments and move "static" info to it.

For performance purposes, our AZ Functions are set to be Always ON.
Because of that, we can initiate and cache some things at the class level so that we don't have to perform those operations every time the FN is invoked.
Create a FunctionConfig class that initializes environment variables and static config files.
Instantiate the FunctionConfig at the class level on the AZ Function class.
For Lake of Segments FN:

[ ] Move Reading Environment variables to Function Config.
[ ] Move eventHubSender to FunctionConfig
[ ] Load BasicProfile config on TransformerSegment init (and cache it in-memory)
[ ] Move TransformerSegment to FunctionConfig and init it there.

Other refactoring:

[ ] Move  val startTime = Date().toIsoString() to inside the messages.forEach loop
[ ] Enhance Logging (See Receiver/Debatcher for template)

[ ]  prefix every logging with "DEX::
[ ]  Log receiving message, sending message and any error (catches should have a logging)
[ ]  Do not include entire message on logs (PII issues). Keep logs short.

PR - https://github.com/CDCgov/data-exchange-hl7/pull/1051


rework PhysX rule

SteamDB app page links to a few games using this
https://steamdb.info/app/237110/
Brief explanation of the change
added another dll to PhysX, so it might get more hits now

it is, 5 letter isn't big enough

because vivox is uncommon, whereas physx isn't

Are you sure there's undetected apps using these dlls, because unless there is, there's no use of merging that pr

Are you sure there's undetected apps using these dlls, because unless there is, there's no use of merging that pr

https://steamdb.info/app/503960/info/

Then only keep the PROFILE change and remove the rest

done

could you reopen the pr? or should i make a new one

run the generate strings script on this branch


Update query-json-files.md

Before my fix, the document said "This query will return each JSON document as a separate row of the result set.", but the above code includes URL to a document which only includes a single JSON document. Therefore, this is not accurate. There is only one JSON document in the source file. The JSON document includes an array of objects and each object is a record which should be converted to a row in the table.
I changed the text to: "The JSON document in the above demo includes an array of objects. This query will return each object as a separate row in the result set."

@pituach : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@jovanpop-msft: I'm sorry - only the author of this article, @azaricstefan, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

#sign-off


Super Mario 3D World has a few broken areas

Played for a few hours today and spotted a couple issues in 5-4 and 5-[]. Using Cemu 1.14 @ 2160 res., gfx pack as of 9/2.

Hi
Forgot to commit Cpt toad fixes to SM3DW, they are in the pull request. Should fix above issue and some other minor stuff like zoom.

Confirmed fix. Thanks!


Remove Splunk Log forwarding from GOV.UK - Part 2

This PR removes the govuk_splunk module from puppet, and stops the
calculators using this module.
Pair: @smford & @fredericfran-gds

This is ready to run after:

#1235 (with fix #1235) in staging to remove the Splunk agent and dependencies.
since the Splunk module was not written with removal in mind, had to also applied temporary PR: #11240

Next time, the best way around might be to delete the Splunk code in Puppet (becomes unmanaged) and then recreate the the calculators_frontend machines in Staging which are the only machines where Splunk is installed.


drop dask from tests

Codecov Report

Merging #2 (e18e911) into main (9fcb958) will increase coverage by 2.84%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##             main        #2      +/-   ##
===========================================
+ Coverage   97.15%   100.00%   +2.84%
===========================================
  Files           8         8
  Lines         527       413     -114
===========================================
- Hits          512       413      -99
+ Misses         15         0      -15

Impacted Files
Coverage Δ

parquetranger/__init__.py
100.00% <100.00%> (ø)

parquetranger/core.py
100.00% <100.00%> (+5.36%)
:arrow_up:

parquetranger/tests/test_core.py
100.00% <100.00%> (ø)

parquetranger/tests/test_parallel.py
100.00% <100.00%> (+2.08%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Replace call_command in feedback export with queryset

This change replaces the call_command call to the feedback export management command with an explicit filtered queryset like the one that that management command constructs. This avoids going through the management command's page lookup path, which is unnecessary when constructing the queryset in code when exporting from the admin.
@chosak it looks like this was your code originally. Could you tell me what you think? Is there stuff we can clean up in the management command where it tries to check if a page is a page or a slug before performing the lookup?
Checklist

[ ] PR has an informative and human-readable title
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the CFPB development guidelines
[ ] Passes all existing automated tests
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged / future todos are captured in comments
[ ] Visually tested in supported browsers and devices (see checklist below :point_down:)
[ ] Project documentation has been updated
[ ] Reviewers requested with the Reviewers tool :arrow_right:

@willbarton the idea behind calling the management command code was to be DRY. With the proposed changes in this PR, the code would have two independent places where the export queryset is constructed (the form where you've changed it and the command itself), and it would be better to have only one. One option would be to create some new, central place for this logic to live (e.g. v1.feedback.FeedbackExporter) and have that be called by both the form and the command.

Is there stuff we can clean up in the management command where it tries to check if a page is a page or a slug before performing the lookup?

As written the management command always assumes that the 'pages' argument it gets here is always a set of Page objects. The conversion from string arguments passed on the command line to Page objects was done through a custom argparse type here. I understand that this has broken somehow with the code changes made for the newer versions of Django. My guess is that this change that changes from passing the pages as pages=pages  to *pages invokes the argparse logic when we don't want it to.
If we could find a fix for invoking the management command properly, would you be open to leaving the current organization? In the commit message for the change mentioned above it says "Django 2.1+ handles positional arguments differently than Django 2.0 in call_command." -- is there a specific place in the Django release notes / tickets that mentions this change?

With the proposed changes in this PR, the code would have two independent places where the export queryset is constructed (the form where you've changed it and the command itself), and it would be better to have only one.

I thought about that, but I'm not sure I feel strongly that assembling a queryset is particularly repetitive. Maybe this kind of query is better suited to being on the Feedback object manager?

If we could find a fix for invoking the management command properly, would you be open to leaving the current organization? In the commit message for the change mentioned above it says "Django 2.1+ handles positional arguments differently than Django 2.0 in call_command." -- is there a specific place in the Django release notes / tickets that mentions this change?

This is the change that broke the previous behavior from my debugging: https://github.com/django/django/pull/9701/files
I believe from the call_command documentation the fix for passing the pages as a keyword argument would be to add a dest to the argparse argument in the management command.

In particular this comprehension:
    parse_args += [
         '{}={}'.format(min(opt.option_strings), arg_options[opt.dest])
          for opt in parser._actions if opt.required and opt.dest in options
     ]

Results in a value error when pages are not given as positional arguments:
ValueError: min() arg is an empty sequence

@chosak I have an alternative approach in 4630e66 that uses call_command and instead of looking up the page slugs in the admin form it passes the slugs to the management command.

@chosak I've settled on just passing page slugs to call_command (which makes the most sense to me).
@higs4281 @cwdavies @Scotchester this is ready for review, I think.

I'm going to merge this. @chosak I'm happy to iterate further if you have anything concerns about how this ended up.


Determine research questions and workshop slides for UnexpecTEDIntentPolicy

Description of Problem:
Based on the UnexpecTEDIntentPolicy post-mortem we will likely try to do some educational workshops about how to use the new policy as well as some research questions we would like to ask developers after they have tried out UnexpecTEDIntentPolicy.
Draft of the questionaire and slide outline is here.
Definition of Done:

[ ] Create slides based on the outline agreed above.
[ ] Schedule a workshop with CSE.
[ ] Deliver the workshop (if it is scheduled within the same sprint).

@TyDunn The next steps are fairly clear in the doc and me / Chris can work on this in one of the upcoming sprints. Our estimate was that we can tick the first two next steps in a sprint. Based on that, do you think we can prioritize it to be taken up next sprint?

@dakshvar22 Let's do it. CSE is aware and ready when we are :)

@dakshvar22 To create the slides, @kedz as reviewer

@kedz @TyDunn Got a bit delayed on this one but first draft of the slides is here. Please feel free to edit / add anything or add comments.
Next steps:

Finish the remaining todos in the slides (by 6th October)
Finalize the slides with @kedz @TyDunn  (by 8th October)
Schedule and deliver the workshop to CSE (by 14th October)

Schedule and deliver the workshop to CSE

Dev Rel would like to be invited and included too

Closing because we delivered the workshop


Not working with unfederated ArcGIS Server

I cannot seems to get the resource proxy to function with unfederated (Built in Security) ArcGIS Server 10.5.1 and return a token. I used to do this all the time but having trouble with latest stuff. Any pointers?
Error:
Token obtained: Exception in generating tokenFailed to generate a token for the user.Client ID is required for long expiration tokens.
Config:

Ok, so I got the PHP proxy working but unable to get the .Net proxy working with the same config.


Make more features compile-time configurable to minimize code size

Not all devices will need e.g. binary string or decimal fraction support. If this can be disabled at compile-time (as it is the case for 64-bit variables), the footprint can be reduced significantly.

Implemented in PR #17.


Pin version numbers

To enable reproducibility of the pipeline, we need to ensure that the tagged source code includes fixed version numbers. The simplest way to do this is to "pin" the versions to a single known working version in requirements.txt of all dependencies, including transitive ones.

Created PR opentargets/data_pipeline#471

PR merged, marking as done for 19.04


Extra characters are inserted in include snippet completion

Here is the problem I'm facing:
https://github.com/clangd/clangd/assets/31820255/9a088831-78e8-4cd2-8332-7a382be19c52
An extra angle bracket is included every time I try to use an include.
System information
Output of clangd --version:
$ clangd --version
clangd version 16.0.2 (https://github.com/llvm/llvm-project 18ddebe1a1a9bde349441631365f0472e9693520)
Features: linux+grpc
Platform: x86_64-unknown-linux-gnu

Editor/LSP plugin:
nvim, nvim-lspconfig
Operating system:
Arch Linux

Duplicate of #1041. The discussion there in turn suggests that this is a bug in the client (nvim), since clangd is sending a correct text edit that's instructing the editor to replace a text range that includes the existing > with the completion text.


Only run dependency-check-maven-plugin in dedicated profile

By default only active in one of the Travis matrix builds (enabled via
environment variable DEPENDENCY_CHECK
This closes #2166

Pull Request Test Coverage Report for Build 5360

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

Totals

Change from base Build 5357:
0.0%

Covered Lines:
15189

Relevant Lines:
27162

💛  - Coveralls

Not sure if this was faster...
A run from another PR looked like this:

Is this working as expected?

Weird.. that must have just been a fluke.  Well, this doesn't look different than the normal builds that run already in the main branch but I don't see the harm of accepting this PR.

@badvision That is a misunderstanding. The profile is active on Travis (i.e. there it is exactly the same build speed). Only local builds without any explicit profiles are a lot faster due to the dependency-check-maven-plugin not being executed then.

Awesome, works for me.  Thanks for cleaning that up!


BUG: problems with unit test workflow

While working on #303, noticed that some unit tests have been failing although the unit test workflow continued and reported success.  This is a problem.  Work on this came to overshadow #314 so that PR was split into two parts, #315 and this issue.

[ ] workflow should indicate if pytest had one or more failed tests
[ ] all failed tests should be resolved
[x] ModuleNotFoundError: No module named 'suitcase'

Related:

#303
#314
#315

This is a common report in the tests:
2023-12-15T14:15:49.3143529Z             |   File "/home/runner/micromamba/envs/hklpy-test-py-3.11/lib/python3.11/site-packages/databroker/mongo_normalized.py", line 1277, in get_serializer
2023-12-15T14:15:49.3143721Z             |     from suitcase.mongo_normalized import Serializer
2023-12-15T14:15:49.3144061Z             | ModuleNotFoundError: No module named 'suitcase'

These tests fail with the hklpy environment (databroker v2):
FAILED hkl/tests/test_save_restore_UB.py::test_fourc_orientation_save - assert 0 == 1
FAILED hkl/tests/test_save_restore_UB.py::test_fourc_run_orientation_info - TypeError: Type is not JSON serializable: _ResultTuple
FAILED hkl/tests/test_save_restore_UB.py::test_list_orientation_runs - TypeError: Type is not JSON serializable: _ResultTuple
FAILED hkl/tests/test_save_restore_UB.py::test_no_primary_stream - TypeError: Type is not JSON serializable: _ResultTuple
FAILED hkl/tests/test_save_restore_UB.py::test_missing_energy_key - TypeError: Type is not JSON serializable: _ResultTuple
FAILED hkl/tests/test_save_restore_UB.py::test_restore_orientation - TypeError: Type is not JSON serializable: _ResultTuple
FAILED hkl/tests/test_save_restore_UB.py::test_restore_sample - TypeError: Type is not JSON serializable: _ResultTuple
FAILED hkl/tests/test_util.py::test_issue215 - TypeError: Type is not JSON serializable: _ResultTuple

and succeed with bluesky_2024_1 environment (databroker 1.2):
hkl/tests/test_save_restore_UB.py::test_fourc_orientation_save PASSED                                                                          [ 12%]
hkl/tests/test_save_restore_UB.py::test_fourc_run_orientation_info PASSED                                                                      [ 25%]
hkl/tests/test_save_restore_UB.py::test_list_orientation_runs PASSED                                                                           [ 37%]
hkl/tests/test_save_restore_UB.py::test_no_primary_stream PASSED                                                                               [ 50%]
hkl/tests/test_save_restore_UB.py::test_missing_energy_key PASSED                                                                              [ 62%]
hkl/tests/test_save_restore_UB.py::test_restore_orientation PASSED                                                                             [ 75%]
hkl/tests/test_save_restore_UB.py::test_restore_sample PASSED                                                                                [ 87%]
hkl/tests/test_util.py::test_issue215 PASSED                                                                                [100%]

suitcase packages in the two environments are identical:
(bluesky_2024_1) prjemian@arf:~/.../Bluesky/hklpy$ conda list suitcase
# packages in environment at /home/prjemian/.conda/envs/bluesky_2024_1:
#
# Name                    Version                   Build  Channel
suitcase-jsonl            0.2.2              pyhd8ed1ab_0    conda-forge
suitcase-mongo            0.4.0              pyhd8ed1ab_0    conda-forge
suitcase-msgpack          0.3.0              pyhd8ed1ab_1    conda-forge
suitcase-utils            0.5.3              pyhd8ed1ab_1    conda-forge
(bluesky_2024_1) prjemian@arf:~/.../Bluesky/hklpy$ conda activate hklpy
(hklpy) prjemian@arf:~/.../Bluesky/hklpy$ conda list suitcase
# packages in environment at /home/prjemian/.conda/envs/hklpy:
#
# Name                    Version                   Build  Channel
suitcase-jsonl            0.2.2              pyhd8ed1ab_0    conda-forge
suitcase-mongo            0.4.0              pyhd8ed1ab_0    conda-forge
suitcase-msgpack          0.3.0              pyhd8ed1ab_1    conda-forge
suitcase-utils            0.5.4              pyhd8ed1ab_0    conda-forge

The point of failure happens as data for a sample reflection is being serialized to JSON.  Starting from the diffractometer's reflections attribute: https://github.com/bluesky/hklpy/blob/e0ba082db35120efa7d01b60af74fad419ce8d84/hkl/diffract.py#L179-L183 https://github.com/bluesky/hklpy/blob/e0ba082db35120efa7d01b60af74fad419ce8d84/hkl/sample.py#L321-L327
The reflections() property returns a list of libhkl.SampleReflection objects.  A SampleReflection object is a ResultTuple (not defined in hklpy source) which renders such as this example: (h=1.0, k=2.0, l=3.0).
Can't convert this object to JSON (from tiled.utils.safe_json_dump()) TypeError: Type is not JSON serializable: _ResultTuple.  The exception is raised by orjson.dumps() from this line in tiled.utils
return orjson.dumps(content, option=orjson.OPT_SERIALIZE_NUMPY, default=default)

We've seen this error before.  But our attention was on the constraints information.  This time, it is reflections.
What has been exceptionally problematic is that this exception did not stop the RunEngine, nor was it exposed to the user.  Instead, the situation was discovered by applying safe_json_dump() to each of the diffractometer's configuration attributes.  This seems to be an upstream problem which hklpy should not try to resolve.

All tests pass locally with databroker v1.2 yet fail with databroker 2.0.  This is a positive situation.  The failures can be attributed to code changes related to databroker v2.  This is understood to be a structural difference.  With databroker v1.2, the documents are from intake while databroker v2 provides tiled Containers.
FAILED hkl/tests/test_util.py::test_issue215 - AssertionError: assert 'fourc' in {}
FAILED hkl/tests/test_util.py::test_RE_documents[None] - AssertionError: assert 'e4cv' in {}
FAILED hkl/tests/test_util.py::test_RE_documents[short] - AssertionError: assert 'e4cv' in {}
FAILED hkl/tests/test_util.py::test_RE_documents[long] - AssertionError: assert 'e4cv' in {}

The common point of failure is this code: https://github.com/bluesky/hklpy/blob/dfb7f1861a7462d30d3847f166e66361f90ad8a5/hkl/util.py#L329-L358


How to connect standalone prometheus to timescaledb

Hi
How to build prometheus-postgresql-adapter for standalone prometheus which is not part of docker.

Found way , using following
git clone https://github.com/timescale/prometheus-postgresql-adapter.git
cd prometheus-postgresql-adapter
go install

@CassDBA closing this issue since issue seems resolved.


added golang support ⚡

@KoNekoD Thanks for the PR. Please provide unit tests so we can detect any regressions in the future.

let's merge it into 1 PR.
1 feature (golang support) - 1 PR

@KoNekoD Is there any update? I'll happily accept the contribution once the CI is fixed


Switch to exchange_calendars forked from trading_calendars?

Maybe switch to exchange_calendars
See e.g. Pandas fix

That's indeed the plan, just need to do some work to prevent unintended consequences.


chore(main): release 1.4.4

:robot: I have created a release beep boop
1.4.4 (2023-04-15)
Styling

Format code with prettier (d44c1de)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/School-of-Website-Engineering/future-front-end/releases/tag/v1.4.4 :sunflower:


Notice: Changes to Bard's Internal API and Policies

Notice: Changes to Bard's Internal API and Policies
It has been observed that the internal API and policies of Bard are currently undergoing changes.
Please collect any errors related to changes in the Google API interface here issue #80 and kindly provide corresponding solutions.
Thank you in advance.
Contributors can adapt to these changes and continue reporting errors. However, if Response Errors persist due to API policy changes within Google, please consider using the following hf-transllm. It is expected that the release of Google's palm2 API is being planned and adjusted in the near future, but the details are not certain.
In addition, you can contribute by fixing any non-functioning features among the currently available ones due to API interface changes, and this applies to all projects I own.
I sincerely appreciate active community contributions!
Furthermore, I am fine-tuning and researching an open-source LLM model, aiming to release a high-quality LLM model soon, allowing users to utilize it like the Bard API. Please bear with me a little longer, and I kindly request your anticipation and interest.
Thank you!
Regards,
Daniel

hf-transllm
If you want to test the open-llama model, which is released under the Apache License (allowing free commercial use) in various languages, you can try using the hf-transllm package. hf-transllm also supports multilingual inference for various LLMs stored in hugging face repository.

Example code of hf-transllm

In case the Google package is no longer available due to policy restrictions, here's a simple example code for using open-source language models (LLMs) in both English and multiple languages.

Usage
For the decoder models provided by Hugging Face, you can easily use them by either following a simple approach or overriding the inference method. You can explore various open-source language models at this link. Through the ranking information from Open LLM Leader Board Report repository, you can find information about good models.
For LLM that use languages other than English
from transllm import LLMtranslator

open_llama3b_kor = LLMtranslator('openlm-research/open_llama_3b', target_lang='ko', translator='google') # Korean

trnaslated_answer = open_llama3b_kor.generate("나와 내 동년배들이 좋아하는 뉴진스에 대해서 알려줘")
print(trnaslated_answer)

For LLM that use English
Refer https://github.com/openlm-research/open_llama or using like this:
from transllm import LLMtranslator

open_llama3b = LLMtranslator('openlm-research/open_llama_3b)

answer = open_llama3b.generate("Tell me about the Korean girl group Newjeans.")
print(answer)

I have updated the package

But still getting the error of

I update and it runs mooth

It is working but it can break at any time, better to use Palm API. https://developers.generativeai.google/guide/palm_api_overview?authuser=1


Allow optional formatProvider argument on toBoolean and other Convert js functions

Some formatting of the files was also done

Related to #1006


Consider omit_local_variable_types for inclusion

The Dart style guide has long recommended omit_local_variable_types. This however is somewhat in conflict with Flutter samples and style.
We should consider the path forward here, and if this can be included in recommended lints.

How about considering a variant of omit_local_variable_types that only flags local variables with a declared type when the variable has an initializing expression whose type is trivial?
There is no need to work on perfecting the notion of 'trivial' here, we just need to recognize some specific cases, e.g.:

A non-collection literal (var x = 1; var y = true; var z = #foo;).
A collection literal with explicit type arguments (var x = <int>[17, 18]; var y = <String, String>{};).
A non-empty collection literal whose elements have the same trivial type (var xs = [1, 2]; but not var ys = [1, 1.5];).
An instance creation, and if generic: with explicit type arguments (var x = C<int>();).

Surely we could add more elements to this list, but again: It is not required that we get a perfect list of trivial types, we just want a useful one.
For a local variable with any other initializing expression a declared type would be tolerated (not required), we just want to get rid of the ones that are actually useless, and that is not true for some of the cases that are currently flagged by omit_local_variable_types (cf. https://github.com/dart-lang/linter/issues/1586).

Currently, omit_local_variable_types is too strict and removes too many useful type information whose omission makes it harder to read the code and requires more context switching to collect type information from various parts of the code base to understand what's going on.
A scaled back version of that lint that only removes obvious types is an interesting idea, though...

See also https://github.com/dart-lang/linter/issues/2591 for discussion along the lines of @eernstg's proposal above.

The variant of omit_local_variable_types that I mentioned here exists today: omit_obvious_local_variable_types.


Textual changes at level 2 and level 3 of the Manage Backup screen.

-Share Recovery Key not RK. Use smaller font if needed.

-Verified this on dev app v1.5.0(260)


Updated projects.csv

Learn Go in ~5mins : https://gist.github.com/prologic/5f6afe9c1b98016ca278f4d507e65510

sorry but this is not a project

sorry but this is not a project


HIP 31: Require manufacturers to include information about the legality of antennas

Rendered: https://github.com/henet/HIP/blob/hip31-antenna-gain/0031-informing-users-about-legal-antenna-usage.md

I agree with the spirit of this proposal (manufacturers providing guidance to customers in how to stay in compliance of local regulation), I don't think this rises to the level of an economic or technical improvement to the Helium network.
My recommendation is that there are hardware manufacturer guidelines that the foundation set up for getting onboarding access (HIP19 can be updated to fit any new ideas) and also rules around maintaining access. Potentially the foundation may want to have rules around revocation (temporary or permanent) as well.
Curious on your thoughts @Scottsigel @Sophi?

I had some doubts whether this proposal was worth a HIP. The reasons why I opted for one anyway were:

It introduces a first (consumer safe) way of "banning" manufacturers
It's very important for Helium to stay legal. The compensation using proof-of-coverage is a very smart invention that really is allowing the Helium network to grow. Sadly it also incentives (possibly unknowingly) breaking the law.

Wouldn't this be an amendment on HIP 19? That approach would seem to address both what @abhay and @timcooijmans have stated.

Agree wholeheartedly that Helium should stay legal.
I am not sure that it is practical to require manufacturers to provide
guidance -  who then verifies that what they provide is accurate and is up
to date? It seems that it would fit better with the onboarding process.
How often do manufacturers mislead customers by selling non-standard
antennas alongside hotspots?
I wonder if selling hotspots with non-standard antennas does in fact
increase coverage (I don't know and am looking into this).
On Sat, May 22, 2021 at 2:47 PM Chris Volkernick @.***>
wrote:

Wouldn't this be an amendment on HIP 19? That approach would seem to
address both what @abhay https://github.com/abhay and @timcooijmans
https://github.com/timcooijmans have stated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/helium/HIP/pull/180#issuecomment-846448620, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJN477QOVHD74VGVSTMHA3TO733NANCNFSM45K2OBQA
.

I don't want to point fingers but several HIP-19 approved manufacturers are selling antennas that are almost impossible (meaning with normal length cables) to use legally in at least the EU without any warning.
And yes increasing coverage by using higher-gain antennas also increases earnings.

@timcooijmans per yesterday what do you think of idea to refactor this into an amendment to HIP19? I'd like to run through that new manufacturing committe for approval, but if they approved and community didn't have objections, It'd just become HIP19 v1.3 or so

@jamiew I wasn't aware the manufacturing committee was already formed. Can proposals be submitted to this committee via HIP? How does this actually work when the committee itself is working behind closed doors?
I also had some discussion with @shawaj if this should be enforced upon manufacturers or should be rewritten in some documentation provided by DeWi / Helium.
My main concern is that most (especially non-professional) hotspot operators are not informed about the legality of using certain antennas (both sold by HIP19 manufacturers as bought elsewhere)

Is it impossible from a manufacturer side to enforce legality of the setup? I don't want to hear news of helium hotspot owners cuffed away, fined into oblivion.
I saw many people operate under the assumption, that nobody was gonna check. Which is true if we are talking 1-2 rule violations, but when we think about dozens or even hundreds of illegal operation in every city, then there will be pushback.
I am especially concerned, because at least for germany owning as little as 2 miners would already technically force you to open a business to run these profit machines and then you aren't in the realm of "private" people breaking the law a little bit, but a company increasing profit by breaching the law. This type of stuff can get out of hand if the opposing side wants to.
We could have legality checks by checking the connection strength of several nearby miners at the very least and eject miners based on that for a period.

@jamiew I wasn't aware the manufacturing committee was already formed. Can proposals be submitted to this committee via HIP? How does this actually work when the committee itself is working behind closed doors? I mean how can I/we discuss this proposal with the committee, gather their feedback, and so on?

I have to defer to @Scottsigel and @Sophi for more on this, as I'm not actively involved with the committee. But I know it's still early so you should expect to hear more

HI @timcooijmans!
We just got started with the committee, which is why there's little information.
Our second meeting will be on June 23rd and @Scottsigel or I will update you afterwards on how we'll all interact.
For now, use email ;)
We are working on setting up a monthly manufacturing call with approved manufacturers and the committee - TBD, but by the end of the month (hopefully) all of these things should be in place.

Not sure if this is helpful, but I'll throw it out there. This feels like a similar problem vendors in R/C FPV (remote control first person view) hobby have, so maybe we can take a similar approach?
Some background: In FPV hobby, a variety of frequencies are used for video and control (433Mhz, 900Mhz, 1.3Ghz, 2.4Ghz, 5.8Ghz are the most common). Just like with LoRA gear, there are transmit power limits and EIRP limits for the equipment being sold. But, most common FPV video transmitters are above the limit allowed by many regulatory domains unless you have an Amateur Radio license (HAM license in the US). To account for this most web shops have a warning on the bottom of all product pages that fall into this category. Examples:
GetFPV

[...snip...]
It is your responsibility to ensure that the use of this product meets the requirements imposed by your government's rules and regulations for RF devices. Do not purchase this product if you are unsure of the government requirements or are not able to comply with them. GetFPV cannot be held responsible for your actions if you purchase and/or use this product in violation of your government's regulations. By agreeing to our terms and conditions during the check-out process, you also agree to have read and to understand this notice.

HobbyKing

Attention Customers
** The use and operation of this product in some countries may require a license based on local government restrictions.  Ensure you check your local government rules before operating this device. **

They are solving for a slightly different problem, but my point is that the customer warning is not very specific and just directs customer to ensure they meet the requirements of their regulatory domain. HobbyKing in particular was fined by the FCC a few years back because even though that had that warning, several video transmitters they sold used frequencies and power levels beyond what even an Amateur Radio license would allow.

I share @timcooijmans fear that the People's network will get penalized when too many users (knowingly or unknowingly) use equipment that submits stronger signals than allowed by law.
Multiple manufacturers promote their highly directive antennas for use with their Helium hotspots, without any mention at all that the combination will likely not be legal. If required, I can show listings by multiple vendors but I would prefer to not single out any specific manufacturers.
Getting into a legal fight, or having equipment seized at customs would hamper the expansion of the network.

This should be covered by FCC cert, or equiv per geography. The cert includes the antenna. So, really from a manufacturers perspective two things are required. 1. note FCC and other region certification, including cert number during shipments, 2. provide information of highest gain and pattern tested and certified which is an allowance by FCC part 15.204(c), requiring testing only with the highest gain antenna of each type that would be used with the transmitter at the maximum output power of that transmitter.  Any antenna of a similar type that did not exceed the antenna gain of tested antennas could be used without retesting.  Manufacturers would be expected to supply a list of acceptable antenna types with applications for equipment authorization. have warning that users are not advised to change antennas, unless they are professional installers conforming with regulatory requirements. 3. provide the warning noted above.

Only following FCC is a bit narrow-minded, since Helium exists outside the US. But following FCC would be a good start.

have warning that users are not advised to change antennas, unless they are professional installers conforming with regulatory requirements. 3. provide the warning noted above.

Currently, the above warning is generally not provided. Instead, vendors often explicitly recommend buying an antenna that exceeds the allowed EIRP.


YEEEAH

Thanks Joffnerd and the other crearles for make an update. I luv u

No worries, keep this for issues please :)


Added new OpenShift in hardened Zero Trust Azure environment doc

Based on new solution for Government customers, created a demo and associated doc on OpenShift on Azure using ZTA Blueprint and hardened OpenShift install

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


[BUG] cds build plugin throws error

Is there an existing issue for this?

[X] I have searched the existing issues

Nature of Your Project
JavaScript, TypeScript
Current Behavior
Since v0.21.1 and #248 the plugion is now bundled.
Running cds buildnow throws an exception:
Error: Illegal priority for  encountered for custom plugin - in this version only priority value '1' is allowed
Expected Behavior
Doen't throws exception.
Steps To Reproduce
run cds build
Environment
- **OS**: Windows 10
- **Node**: v20.13.1
- **npm**: 10.8.0
- **cds-typer**: 0.21.1
- **cds**: cds-dk [7.9.2], cds [7.9.2], compiler [4.9.4]

Repository Containing a Minimal Reproducible Example
No response
Anything else?
From @sap\cds-dk\lib\build\buildTaskEngine.js:214:19:

Hi Daniel,
thanks for pointing this out! This happens because I had expected cds8 to be available by now (which is required for this build task to work).
So this is currently a rather unfortunate error message that will automagically fix itself as soon as you are using cds8 (yet to be released!).
Sorry for the inconvenience!
Best,
Daniel

Starting with the upcoming release of cds-typer, the build task will only attempt to run if cds8 is in place to not confront users with this ugly error.
Again, once cds8 is released and in use this problem will go away, but I see how the current output is confusing to users. Thanks again for pointing it out!


Add support of testing standard LB and fix e2e docs

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

/kind documentation
What this PR does / why we need it:
Add support of testing standard LB and fix e2e docs.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Release note:
Add support of testing standard LB and fix e2e docs

/test pull-cloud-provider-azure-e2e

@feiskyer -- is there a good reason to not just make the default SKU Standard instead?

@feiskyer -- is there a good reason to not just make the default SKU Standard instead?

Both standard and basic are supported today, and actually most customers are using basic SKU today.

/lgtm
/approve


Unbound: modifying an override alias from just hostname to hostname+domain throws error

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
I added an alias to an existing unbound override. I realised then that I needed to also override the domain, so I edited the alias, added it and hit save. At this point I was greeted with the following error:
/usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiMutableModelControllerBase.php:443: Too few arguments to function OPNsense\Base\ApiMutableModelControllerBase::setBase(), 2 passed in /usr/local/opnsense/mvc/app/controllers/OPNsense/Unbound/Api/SettingsController.php on line 213 and at least 3 expected

To Reproduce
Steps to reproduce the behavior:

Add an alias to an unbound override without domain
Edit the alias and add the domain
hit save

Expected behavior
Alias is edited without error
Environment
OPNsense 22.1.5-amd64

Maybe browser issue, the "add" button should be hidden when no domain is selected. couldn't reproduce this on my end.

I can reproduce this. Screenshot of the exception:

Ah, I think this might be a misunderstanding. We are talking of leaving the field "Domain" empty, not "Host override".

Debugging data from the Reporter (PHP Error):

[10-Apr-2022 15:33:40 Europe/Berlin] ArgumentCountError: Too few arguments to function OPNsense\Base\ApiMutableModelControllerBase::setBase(), 2 passed in /usr/local/opnsense/mvc/app/controllers/OPNsense/Unbound/Api/SettingsController.php on line 213 and at least 3 expected in /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiMutableModelControllerBase.php:443
Stack trace:
#0 /usr/local/opnsense/mvc/app/controllers/OPNsense/Unbound/Api/SettingsController.php(213): OPNsense\Base\ApiMutableModelControllerBase->setBase('alias', 'aliases.alias')
#1 [internal function]: OPNsense\Unbound\Api\SettingsController->setHostAliasAction('581e5ab4-54ed-4...')
#2 [internal function]: Phalcon\Dispatcher\AbstractDispatcher->callActionMethod(Object(OPNsense\Unbound\Api\SettingsController), 'setHostAliasAct...', Array)
#3 [internal function]: Phalcon\Dispatcher\AbstractDispatcher->dispatch()
#4 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle('/api/unbound/se...')
#5 {main}
[10-Apr-2022 15:44:15 Europe/Berlin] ArgumentCountError: Too few arguments to function OPNsense\Base\ApiMutableModelControllerBase::setBase(), 2 passed in /usr/local/opnsense/mvc/app/controllers/OPNsense/Unbound/Api/SettingsController.php on line 213 and at least 3 expected in /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiMutableModelControllerBase.php:443
Stack trace:
#0 /usr/local/opnsense/mvc/app/controllers/OPNsense/Unbound/Api/SettingsController.php(213): OPNsense\Base\ApiMutableModelControllerBase->setBase('alias', 'aliases.alias')
#1 [internal function]: OPNsense\Unbound\Api\SettingsController->setHostAliasAction('581e5ab4-54ed-4...')
#2 [internal function]: Phalcon\Dispatcher\AbstractDispatcher->callActionMethod(Object(OPNsense\Unbound\Api\SettingsController), 'setHostAliasAct...', Array)
#3 [internal function]: Phalcon\Dispatcher\AbstractDispatcher->dispatch()
#4 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle('/api/unbound/se...')
#5 {main}

@jdeluyck @Starkstromkonsument thanks, https://github.com/opnsense/core/commit/44b669d8ffc3ad5e78f3526e7bb37dd0bdb95891 should fix it.

cc @swhite2

It works perfectly now, thank you.

@Starkstromkonsument Thanks for confirming, we'll make sure these changes hit a release version as soon as possible.


Respect hashes in constraints files

Summary
Like pip, if hashes are present on both the requirement and the constraint, we prefer the requirement.
Closes #7089.

@alex -- Do you have an opinion on what's correct, if both a requirement and a constraint for a given package-version include --hash?

I guess there's three cases:

They have the same hashes, that's fine, that's ok.
One of them has a subset of the others' hashes. If constraint has a subset of requirements' hashes, I think that should act as a "filter" -- effectively it's constraining the set of valid hashes. If requirements' hashes are a subset of constraints hashes, error?
If they just disagree: Error.

But that seems kind of complicated: So really: same == fine, different == error is probably sufficient.

For now, I went with what I observe from pip's behavior, but I may change prior to merging. I see some pip issues that suggest they want to be using the intersection, but I don't see that behavior locally.

Sounds good. Thanks
On Thu, Sep 5, 2024 at 2:41 PM Charlie Marsh @.***>
wrote:

For now, I went with what I observe from pip's behavior, but I may change
prior to merging. I see some pip issues that suggest they want to be using
the intersection, but I don't see that behavior locally.
—
Reply to this email directly, view it on GitHub
https://github.com/astral-sh/uv/pull/7093#issuecomment-2332405605, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAGBEQ37FR3BDFFJAMROLZVCQUFAVCNFSM6AAAAABNXAJTGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZSGQYDKNRQGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
All that is necessary for evil to succeed is for good people to do nothing.

For now, I went with what I observe from pip's behavior, but I may change prior to merging. I see some pip issues that suggest they want to be using the intersection, but I don't see that behavior locally.

The latest discussion is about dropping support for hashes in constraints: https://github.com/pypa/pip/issues/12942#issuecomment-2332158690
In practise hashes in constraints files don't really work as they imply require hashes, but the requires hashes errors unless the hash is in the requirements file.
I think uv has quite a bit of leeway here to choose what it thinks is best.

What's the motivation for dropping support there?

What's the motivation for dropping support there?

As I understand it (and I've not spent time reviewing the code, I'm just basing this on what I've read in comments) constraints are implemented as a collection filter where hashes are not checked, and are not part of resolution verification where hashes can be checked.
Currently pip only allows hashes to be specified if you pin the requirement, and adding a hash implies requiring hashes, this leads to the behaviour of:

Create constraints.txt with the contents:

setuptools==74.1.1 --hash=sha256:fc91b5f89e392ef5b77fe143b17e32f65d3024744fba66dc3afe07201684d766

Run pip install setuptools==74.1.1 -c constraints.txt, and get error:

ERROR: Hashes are required in --require-hashes mode, but they are missing from some requirements. Here is a list of those requirements along with the hashes their downloaded archives actually had. Add lines like these to your requirements files to prevent tampering. (If you did not enable --require-hashes manually, note that it turns on automatically when any package has a hash.)
	setuptools==74.1.1 --hash=sha256:fc91b5f89e392ef5b77fe143b17e32f65d3024744fba66dc3afe07201684d766

I would love for pip to support this use case (and hence also uv), but I'm not going to be the one to drive large architectural changes on the pip side.

Ahh ok I see. Yeah we can support it, it's structured slightly differently here. Not sure what's best though: union, intersection, ignroing one or the other, etc.

IMO a constraint should "constrain" the solution. Which I think would be an intersection?
A requirements of:
foo==1.0.0 --hash=sha256:{hashA} --hash=sha256:{hashB}
bar==1.0.0
baz

With a constains file of:
foo==1.0.0 --hash=sha256:{hashB} --hash=sha256:{hashC}
bar==1.0.0 --hash=sha256:{hashD}
baz==1.0.0 --hash=sha256:{hashE}

For those packages the should should only be able to have:
foo==1.0.0 --hash=sha256:{hashB}
bar==1.0.0 --hash=sha256:{hashD}
baz==1.0.0 --hash=sha256:{hashE}

Does that make sense?


[Bug] Starting any example app throws an exception

To Reproduce
Start any application from a clean clone of the repo.
Screenshots

Does it happen in WPF version?
No.

Fixed https://github.com/BAndysc/nodify-avalonia/commit/2a059a3a6e50b70661863b8eaa2ae792723467a1