When setting tag in helm values file, upgrade fails

Report
On an already installed add-on, when setting the images->tag to some other value (for example 0.4.0) it fails when executing
helm upgrade --install http-add-on kedacore/keda-add-ons-http --namespace keda --values kedahttp.values.yaml
with
Error: UPGRADE FAILED: cannot patch "keda-add-ons-http-interceptor" with kind Deployment: Deployment.apps "keda-add-ons-http-interceptor" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"control-plane":"interceptor", "httpscaledobjects.http.keda.sh/version":"0.4.0", "keda.sh/addon":"keda-add-ons-http"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "keda-add-ons-http-controller-manager" with kind Deployment: Deployment.apps "keda-add-ons-http-controller-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"control-plane":"controller-manager", "httpscaledobjects.http.keda.sh/version":"0.4.0", "keda.sh/addon":"keda-add-ons-http"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "keda-add-ons-http-external-scaler" with kind Deployment: Deployment.apps "keda-add-ons-http-external-scaler" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"control-plane":"external-scaler", "httpscaledobjects.http.keda.sh/version":"0.4.0", "keda.sh/addon":"keda-add-ons-http"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable
Removing the release and rerunning succeeds.
Expected Behavior
Updated release with new image tag
Actual Behavior
Nothing. Release did not get updated
Steps to Reproduce the Problem

Install add-on with default values
Set images-> tag to daa5900
upgrade release

Logs from KEDA HTTP operator
example

What version of the KEDA HTTP Add-on are you running?
0.4.0
Kubernetes Version
1.26
Platform
Other
Anything else?
No response

Can you try try the latest version please?

It looks like we have changed the selector, adding a breaking change (we didn't notice it, sorry)
I'd suggest removing the deployments and then upgrading the chart again to redeploy the deployments with the correct selectors.
In the future, we should be more careful with these changes

Thanks for replying, will do

If we uninstall and install the http-add-on, it's not installing the CRD, and we need to remove the scaled objects as mentioned in https://github.com/kedacore/keda/issues/4392, again we need to install the http-add-on, also we need to redeploy the apps. Please add this breaking change to the installation document.

You're right, I have just updated the release notes.
Sorry for the inconveniences

I am seeing a similar behaviour with upgrading from version 0.6.0 to 0.70. Seems like the version label selectors have made their way into the config again. Can you confirm that is the case please?
spec:   progressDeadlineSeconds: 600   replicas: 1   revisionHistoryLimit: 10   selector:     matchLabels:       app.kubernetes.io/component: interceptor       app.kubernetes.io/instance: http-add-on       app.kubernetes.io/managed-by: Helm       app.kubernetes.io/part-of: keda-add-ons-http       app.kubernetes.io/version: 0.6.0       helm.sh/chart: keda-add-ons-http-0.6.0`

I am seeing a similar behaviour with upgrading from version 0.6.0 to 0.7.0. Seems like the version label selectors have made their way into the config again. Can you confirm that is the case please?
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/component: interceptor
      app.kubernetes.io/instance: http-add-on
      app.kubernetes.io/managed-by: Helm
      app.kubernetes.io/part-of: keda-add-ons-http
      app.kubernetes.io/version: 0.6.0
      helm.sh/chart: `keda-add-ons-http-0.6.0

What is this?
I've just deployed the chart 0.7.0 and I can't see that :/

I am seeing a similar behaviour with upgrading from version 0.6.0 to 0.7.0. Seems like the version label selectors have made their way into the config again. Can you confirm that is the case please?
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/component: interceptor
      app.kubernetes.io/instance: http-add-on
      app.kubernetes.io/managed-by: Helm
      app.kubernetes.io/part-of: keda-add-ons-http
      app.kubernetes.io/version: 0.6.0
      helm.sh/chart: `keda-add-ons-http-0.6.0

What is this? I've just deployed the chart 0.7.0 and I can't see that :/

The exact error I got is this:
Error: UPGRADE FAILED: cannot patch "keda-add-ons-http-interceptor" with kind Deployment: Deployment.apps "keda-add-ons-http-interceptor" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/component":"interceptor", "app.kubernetes.io/instance":"http-add-on", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/part-of":"keda-add-ons-http", "app.kubernetes.io/version":"0.7.0", "helm.sh/chart":"keda-add-ons-http-0.7.0"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "keda-add-ons-http-controller-manager" with kind Deployment: Deployment.apps "keda-add-ons-http-controller-manager" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/component":"operator", "app.kubernetes.io/instance":"http-add-on", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/part-of":"keda-add-ons-http", "app.kubernetes.io/version":"0.7.0", "helm.sh/chart":"keda-add-ons-http-0.7.0"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "keda-add-ons-http-external-scaler" with kind Deployment: Deployment.apps "keda-add-ons-http-external-scaler" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app.kubernetes.io/component":"scaler", "app.kubernetes.io/instance":"http-add-on", "app.kubernetes.io/managed-by":"Helm", "app.kubernetes.io/part-of":"keda-add-ons-http", "app.kubernetes.io/version":"0.7.0", "helm.sh/chart":"keda-add-ons-http-0.7.0"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

oh, f**k!
I can reproduce it, so I'd say that it's still happening :(. Thanks for reporting it

I think that we have something wrong in the helm chart: https://github.com/kedacore/charts/tree/main/http-add-on
Are you willing to take a look and draft a PR?

Thanks for reporting the problem, I've reviewed the chart and I found the root cause. This PR fixes it and we will cut a release soon including it.
Sadly to upgrade (once it's released) you will have to remove the deployments once again, but I hope that this will be the last time

Thanks for reporting the problem, I've reviewed the chart and I found the root cause. This PR fixes it and we will cut a release soon including it.
Sadly to upgrade (once it's released) you will have to remove the deployments once again, but I hope that this will be the last time

Thanks for looking into this @JorTurFer, sorry I didnt get around to look into it like you requested. Will this fix be merged as part of the current 0.7.0 version or will it be packaged in as part of 0.8.0 release

I plan to cut a helm release (0.7.1) once the PR is merged as this is breaking the upgrade to any new user who installs the chart


Top menu bar has a broken comment

On every page, on the top menu bar there's a broken comment:
"// put a menu here? https://github.com/jdf/processing-py-site/issues/169 "
This should be either changed with an html comment <!-- Comment --> or removed since the menu bar is now there.

Well spotted, @Signum21
I've corrected this and submitted a pull request (#199)

I just came from this page https://py.processing.org/ because I saw the comment there.


[Docs] Add description of MeshMates program.

Current State:
MeshMates is our newcomer onboarding program. It is described in brief here - https://layer5.io/community and in full here - https://docs.google.com/document/d/1vquQMD0TTWREahpx_JXuvIbQ4hM2_4jrVFk8xqZ72ok/edit
Desired State:
This program should be included in:

[ ]  the Community page.

@itsapoorvj Would you like to knock this out ?

Sure!!

@kushthedude , Its already added in community page: https://layer5.io/community

@itsapoorvj, it needs to be added here https://meshery.io/community/

The community page of meshery is already occupied by the contributors, adding the program details on it will make the page ugly. @leecalcote How about adding a new page for the mentoring initiatives & the programs in which Meshery has participated?

The community page of meshery is already occupied by the contributors, adding the program details on it will make the page ugly. @leecalcote How about adding a new page for the mentoring initiatives & the programs in which Meshery has participated?

Agree !

Gents, good suggestion. Sounds real good.

@ashiscs has the page been created?

@ashiscs has the page been created?

No, i guess @Ruth-ikegah

@ashiscs has the page been created?

No, i guess @Ruth-ikegah

I can find it on layer5.io site but not on meshery.io

@Ruth-ikegah given the description of the MeshMates program on the layer5.io site, instead of capturing a description of the program directly on meshery.io, let's link to the description on layer5.io/community/meshmates. This link can be included on any member profile that has the MeshMate title.
@Ruth-ikegah here is an issue that we really would like to see implemented - https://github.com/layer5io/meshery.io/issues/209.

@Ruth-ikegah given the description of the MeshMates program on the layer5.io site, instead of capturing a description of the program directly on meshery.io, let's link to the description on layer5.io/community/meshmates. This link can be included on any member profile that has the MeshMate title.
@Ruth-ikegah here is an issue that we really would like to see implemented - #209.

Cool, I'd check out the issue.

transitioning the majority of the community member profiles and the MeshMate program description to layer5.io/community


Animation seems to be broken

Hi, the animation under the password input field seems to do crazy stuff .. have you may noticed anything? I tested in Chrome, Safari and Firefox.

Hi, I just tested it with a fresh "bower install" and the demo page. Does the demo page also behave weird? I could not reproduce this.

Sorry my fault, I forgot the angular-bootstrap-pwgen.css file !!


Add TSPA Abuse Type Explainer Pop Up

From II Slack:

could you put an explainer on what TSPA abuse-type categories are — we know what TSPA is, but people outside the field might not

Added a "Learn More" button.


Proper use of DataTemplateView to add close button to tabs.

I've been trying to implement a very simple close button on a tab control. To do this I've been using the DataTemplateView class transform the header into a name and a button. I attach a function that dispatches the a Close message and the tab's GUID as a tuple. The tab with the respective GUID is then removed from the list of tabs. The individual tab is implemented in the module Page with it's respective State, Msg, update, and view:
module Page =

    let private tabView closeFunc (name:string) =
        let components =
            DockPanel.create [
                DockPanel.children [
                    Button.create [ Button.dock Dock.Right
                                    Button.content "x"
                                    Button.onClick closeFunc ]
                    TextBlock.create [ TextBlock.text name
                                       TextBlock.dock Dock.Left]
                    ]
                ]
        Border.create [ Border.child components ]

    let tabHeader closeFunc =
        tabView closeFunc
        |> DataTemplateView<string>.create

    type State =
        { uid : System.Guid }

    type Msg =
        | Noop
        | Close

    let init uid =
        { uid = uid }

    let update (msg:Msg) (state:State) =
        match msg with
        | Noop -> state
        | _ -> printfn "SHOULD NOT HAPPEN" ; state

    let view (state:State) dispatch : Avalonia.FuncUI.Types.IView =
        let content = TextBox.create [TextBox.text "Hello"]
        let closeFunc (_:'a) =
            dispatch Close
        TabItem.create
            [
                TabItem.header (state.uid.ToString().Substring(0,4))
                TabItem.headerTemplate (tabHeader closeFunc)
                TabItem.content content
            ]

The main part of the program is implemented in Shell. Each page is an element in a list contained in the top level state. In the update function I use List.filter to remove the page with the GUID specified in the the message.
module Shell =

    type State =
        { devicePages : Page.State list }

    type Msg =
        | Msg of System.Guid * Page.Msg

    let init =
        { devicePages = List.map (fun _ -> {uid = System.Guid.NewGuid()} ) [0..3] },
        Cmd.none

    let update (msg: Msg) (state: State): State * Cmd<_> =
        match msg with
        | Msg (uid,Page.Msg.Close) ->
            {state with devicePages = List.filter (fun st -> st.uid <> uid) state.devicePages},
            Cmd.none
        | Msg (_,_) ->
            state, Cmd.none

    let view (state: State) dispatch =
        let deviceDispatch uid msg =
            Msg(uid,msg) |> dispatch

        TabControl.create
                [ TabControl.classes ["shell"]
                  TabControl.tabStripPlacement Dock.Top
                  TabControl.viewItems
                      [ yield! List.map (fun st -> Page.view st (deviceDispatch st.uid)) state.devicePages ]
                ]

However, this doesn't seem to work. I can close tabs if I work from right to left (from the end of the list to the root) but if I try to work from the left to the right then I get "stuck" tabs that don't want to close. For example, if I have four tabs, if I close the first one then I will have three tabs but I won't be able to close the tab that is now in the first position. Have I misused the DataTemplateView class or is there a more fundamental problem?
I've omitted some of the code for brevity. A full working project can be found at: https://github.com/marekhilton/TabTestIssue

First thought would be that the following might fix it.
Functions/Delegates don't support equality so FuncUI does not know if it needs to patch the onClick handler.
..
Button.create [
    Button.dock Dock.Right
    Button.content "x"
    Button.onClick (closeFunc, SubPatchOptions.OnChangeOf name)
]
..

I'd recommend you to take a look at the PR branch . Will be merged soon and makes building apps a lot simpler.

By the way I forgot to say thank you making such an awesome project!
I thought it would be probably be something to do with functions not supporting equality. But using SubPatchOptions.OnChangeOf or SubPatchOptions.Always doesn't seem to make a difference.
I will check out that branch, looks exciting!


Style: Update Toolhint Z-Index and Add Toolhint for GlobalEnvironmentSelector

fixes: #3278
Description
This PR implements a style fix for the Toolhint component. I have added the z-index for the Toolhint (Tooltip's) UI, allowing it to rise above the tab scroll and the 'Add Request' button when multiple tabs are open.
Additionally, I've added the Tooltip for the GlobalEnvironmentSelector component.
Contribution Checklist:

[x] The pull request only addresses one issue or adds one feature.
[x] The pull request does not introduce any breaking changes
[x] I have added screenshots or gifs to help explain the change if applicable.
[x] I have read the contribution guidelines.
[x] Create an issue and link to the pull request.

Before:

After:

Thanks @Pragadesh-45 !


Fix compilations+static analysis issues

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (b192f43) 79.98% compared to head (8bc33b1) 83.34%.

Files
Patch %
Lines

Pyext/src/ecflow/python/BoostPythonUtil.cpp
80.00%
2 Missing :warning:

ACore/test/TestStr.cpp
0.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop      #77      +/-   ##
===========================================
+ Coverage    79.98%   83.34%   +3.35%
===========================================
  Files          626      590      -36
  Lines        58002    52614    -5388
===========================================
- Hits         46394    43849    -2545
+ Misses       11608     8765    -2843

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fixup for pypi distribution of pyhsmm

I missed one wrinkle with pypi distribution. The previous version didn't include the *.pyx files in the distribution, and so the package from pypi would install correctly but would not compile the Cython files.
For now, I included the Cython files and associated headers through MANIFEST.in. This will make it so when you install the package from pypi, the installation procedure automatically compiles the Cython files. A more ideal solution would be to write a conditional in the setup.py that checks if Cython is present, and if so, compiles the Cython files. For developers who want to make a distribution with python setup.py sdist, only the Cython-generated *.c files would go in the distribution, and then users could install with just Python and a C compiler, without needing Cython. (This more ideal setup is described here: http://stackoverflow.com/questions/4505747/how-should-i-structure-a-python-package-that-contains-cython-code). Since your users are mostly expert developers who probably have Cython, I figured it's not pressing.
One caveat to watch out for: if you compile your pyx files to make *.c files, and have something that includes all *.c files in MANIFEST.in, you could accidentally package a Cython generated, e.g.  foo.c along with a foo.pyx file. That could might create a situation where only the foo.c gets used even if it's out of date with the foo.pyx file. So to be on safe side, best to wipe out all Cython generated files before making a source distribution, i.e. before running python setup.py sdist.
I fixed this in pybasicbayes too, see other pull request.
It'd be great if you could make a fresh source distribution and upload it to pypi. You could wipe out the previous one through the pypi admin settings, or upgrade the VERSION variable in setup.py and make a new version release. I'm sure that if you wipe out the previous one and replace it without changing the version, you won't upset anyone, it has only been out for a few hours :)

Can you rebase this onto the current master?

Actually, wiping and replacing it without changing the version doesn't work anymore!
I'm somewhat confused here. When I run sdist it looks like the .cpp files are being included in pyhsmm, i.e. it prints stuff like
hard linking pyhsmm/internals/hmm_messages_interface.cpp -> pyhsmm-0.1.1/pyhsmm/internals

I also made some updates to setup.py so that it should default to building the .cpp sources included in the pypi distribution, and made a fix to the cythonize(./pyhsmm... line like you did.
So can you check out the current master and/or the current pypi distribution and see what's actually still broken? In the meantime, I'll try to read and understand your comments better.

Here's the new setup.py bit I'm talking about. I think the only thing left to ensure is that the .cpp files are in the pypi distribution.

I downloaded the tarball from the pypi page and it definitely includes the .cpp files (but not the pyx files). I guess that's a default? In that case, maybe we only have to add the .pyx bit to Manifest.in?

It depends which cpp files you're referring to. The ones from Eigen are taken care of because I already had recursive-include deps * in MANIFEST.in -- so that includes everything in deps which includes all the Eigen3 files. Any other cpp files would not be included.
I'm not totally sure how to rebase - I might just rebuilt my changes into your current version, I'm not good with git.

The other cpp files are being included though; you can see it by downloading the tarball from the pypi page yourself. I've also been testing directly with the tarball generated in dist by the sdist command and I'm pretty confident that adding *.pyx to Manifest.in is all that's necessary.
I'm going to push that change, update the pypi package, and close this PR for now. If I'm mistaken about something, i.e. if the pypi tarball doesn't include both the pyhsmm (non-Eigen) cpp files and the pyx files, then we can reopen it.

I am looking at the tarball - unless you uploaded a new one, I still think it's missing stuff. For example, there's no *.h files in internals:
$ ls pyhsmm-0.1.1/pyhsmm/internals/*.h
ls: pyhsmm-0.1.1/pyhsmm/internals/*.h: No such file or directory

but clearly they should be there:
$ ls pyhsmm/internals/*.h
pyhsmm/internals/hmm_messages.h  pyhsmm/internals/nptypes.h
pyhsmm/internals/hsmm_messages.h pyhsmm/internals/util.h

my changes to MANIFEST.in fix that.

It does include the cpp files automatically though, right? That tarball you downloaded was generated with a Manifest.in that only referenced the Eigen stuff.
You're right that the .h files are necessary to build from the pyx files (though I'm not sure if they're necessary to build from the cpp files, since they're never #included and the compile line doesn't reference them in any way).
It's too bad I had just pushed that. Incrementing the version number again I guess...

Okay, in b65ab07 the Manifest.in file has these lines
recursive-include pyhsmm/deps *
recursive-include pyhsmm *.pyx
recursive-include pyhsmm *.h

That definitely includes the pyx files, the cpp files, and the h files in pyhsmm/internals in the generated tarball.
However I will learn from my mistakes and not push it to pypi immediately! I'm pretty sure this is right this time, but let me know if I'm missing anything...

Ah okay, here's why the .cpp files were included:

If you don’t supply an explicit list of files (or instructions on how to generate one), the sdist command puts a minimal default set into the source distribution:

all Python source files implied by the py_modules and packages options
all C source files mentioned in the ext_modules or libraries options
[...]

So it got slurped up via the ext_modules. If I had included the header files in the sources of each Extension instance, they would have gotten included too.

Ah I see. Your cythonize did seem much simpler than what I've had in past. This is a setup.py file I wrote a long time ago that conditionally compiles Cython files, and adds a "clean" option to wipe out Cython files for developers: https://github.com/yarden/MISO/blob/newmiso/setup.py
I defined each Cython file as an Extension so I guess that's why I never had to include the *.h files explicitly.

Aaaaaand here's the docstring for the add_defaults method for the sdist class in distutils/command/sdist.py:
    def add_defaults(self):
        """Add all the default files to self.filelist:
          - README or README.txt
          - setup.py
          - test/test*.py
          - all pure Python modules mentioned in setup script
          - all files pointed by package_data (build_py)
          - all files defined in data_files.
          - all files defined as scripts.
          - all C sources listed as part of extensions or C libraries
            in the setup script (doesn't catch C headers!)
        Warns if (README or README.txt) or setup.py are missing; everything
        else is optional.
        """

I've been trigger happy with pypi before... it's so unforgiving. :(

Thanks for the reference on your cython setup.py file.
I think it is more typical to explicitly build the extension modules as Extension instances in setup.py. But the cythonize (which is fairly recent) has that great globbing functionality, plus it reads fields like extra_compile_args from the top of the pyx file ("distutils processing" or something). I preferred that style because it meant the information needed to compile a pyx file would stay with the pyx file instead of being buried in a setup.py. It also makes including projects in other projects was easy, since a recursive cythonize command can find all the pyx files and have everything it needs to build them.

At this rate we'll be at version 9999 in no time!
I find this distutils stuff shockingly under-documented and frustrating, but maybe I just wasn't patient enough with it to learn its ways.

Thanks again for your help with this! You did all the work here and it would have taken me a while to figure this stuff out (if I didn't give up in frustration). This is really going to help people with installation and compilation (including future me).

My pleasure! pyhsmm is awesome and I think it'll help people (like me) build libraries that depend on it since it can be installed automatically. I completely agree the distutils stuff can be awful, especially when Cython's involved. But once there's a stable release on pypi it's really nice as a reference point and for making pipelines that are guaranteed to work for a specific version and do not depend on git.

Late to the party, but this is excellent!


[MNOE-833] - Fix wrong entity sent back on user creation

I think it should be ported on 4.0 @ouranos

Thanks.
Yes I'll merge  3.3 into 4.0 later


[SPARK-19940][ML][MINOR] FPGrowthModel.transform should skip duplicated items

What changes were proposed in this pull request?
This commit moved distinct in its intended place to avoid duplicated predictions and adds unit test covering the issue.
How was this patch tested?
Unit tests.

Test build #74467 has started for PR 17283 at commit 6183093.

Test build #74467 has finished for PR 17283 at commit 6183093.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74467/
Test FAILed.

Test build #74469 has started for PR 17283 at commit 1edf3fa.

Test build #74470 has started for PR 17283 at commit 7a44dbe.

Test build #74469 has finished for PR 17283 at commit 1edf3fa.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74469/
Test PASSed.

Test build #74470 has finished for PR 17283 at commit 7a44dbe.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74470/
Test PASSed.

Test build #74519 has started for PR 17283 at commit d292896.

Test build #74519 has finished for PR 17283 at commit d292896.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74519/
Test PASSed.

Thanks for fixing this issue!  LGTM
Merging with master
Stating the JIRA number for a bug fix is reasonable, though it's most useful if the bug appears in an actual release.


Code for multiple prompt input

Hi, would you consider adding support for multiple prompts, i.e. motion injection, in FreeNoise in this code base?

Hi, would you consider adding support for multiple prompts, i.e. motion injection, in FreeNoise in this code base?

Hi, temporally no plan for it. Will consider it if many people need this feature.


Add check for base models in Stack

Closes #861

Codecov Report

Merging #877 (863e807) into dev (0f16a63) will decrease coverage by 0.48%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev     #877      +/-   ##
==========================================
- Coverage   85.32%   84.84%   -0.49%
==========================================
  Files          40       40
  Lines        3557     3549       -8
==========================================
- Hits         3035     3011      -24
- Misses        522      538      +16

Impacted Files
Coverage Δ

src/composition/models/stacking.jl
95.90% <100.00%> (+0.17%)
:arrow_up:

src/measures/loss_functions_interface.jl
59.25% <0.00%> (-13.96%)
:arrow_down:

src/measures/confusion_matrix.jl
90.09% <0.00%> (-4.51%)
:arrow_down:

src/measures/continuous.jl
89.58% <0.00%> (-3.01%)
:arrow_down:

src/measures/probabilistic.jl
61.64% <0.00%> (-1.52%)
:arrow_down:

src/utilities.jl
83.54% <0.00%> (-1.27%)
:arrow_down:

src/machines.jl
90.04% <0.00%> (-0.42%)
:arrow_down:

src/measures/finite.jl
98.58% <0.00%> (-0.02%)
:arrow_down:

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

@olivierlabayle Do you have time and interest to review this short PR in the next week or so?

@olivierlabayle Do you have time and interest to review this short PR in the next week or so?

Sure will do!

Unrelated to this PR but locally one test fail on my mac due to what seems to be an ambigouous method definition:
integration 5: Error During Test at /Users/olivierlabayle/Dev/JuliaAI/MLJBase.jl/test/composition/models/pipelines.jl:518
  Got exception outside of a @test
  MethodError: fit(::StaticPipeline{NamedTuple{(:f, :my_transformer3), Tuple{Any, Static}}, MLJModelInterface.predict}, ::Int64) is ambiguous.  Can you please post your environment details?

@olivierlabayle I'm not getting any fails. Can you please post your environment details?
And Julia version (method ambiguities seem to vary over versions). I've been testing on 1.8.5

Hum I've upgraded from 1.8.1 to 1.8.5 and tried with both macOS x86 and macOS ARM but the exact same error occurs... I've also pushed a CI update including macOS which seems to run perfectly fine (reverted now)... Strange, I will blame my local install and happy to move on.

@olivierlabayle Thanks for the further investigation on the fail. I'm not convinced this has something to do with your installation. This just shouldn't be happening.
Would you mind opening a new issue with the stack trace. I will want to investigate a little further and see if others can reproduce.


Adding tip to explain ASM unsubscribe groups

Description of the change:
Reason for the change:
Link to original source:

Closes #

Hello @Whatthefoxsays,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


Break up the inital API query into smaller chunks.

Currently, the initlal query when the site is loaded requests a large amount of data. Due to this the caching service (Stellate) is unable to handle the request and passes the request onto the API directly. This results in a large amount of unnecessary data being processed through the workers.
https://github.com/the-hideout/tarkov-dev/blob/e0df91ed21ec7690a1bdaa568a7c523d496a2c07/src/features/items/do-fetch-items.js#L6
Can we possibly request the data in "chunks" of 500-1000 item using the limit and offset params so we can hit the Stellate cache and increase the initial data load speed? This issue came to light tonight when the workers were unable to handle the increased load due to a cache/kv issue and ended us 503ing most website users with an out of memory error.
@Shebuka Thoughts?

This is a very good idea to get those requests hitting the cache, and I think fairly easy to implement. The downside is that due to how the API works, I think it might make the time this query takes scale basically linearly with the amount of "chunks" it's broken into and when it's retrieving an un-cached version.

We can probably do this and split it into chunks, but I don't see what benefits this gives us. It will slow down the loading of the site and not help us in any way when other API users query for the full request 🤔

The benefit would be that the smaller chunks always would hit the stellate cache, which is always fast.


Update the ControlInstruction to support getting a file from the serv…

…er into a ecmdDataBuffer
Signed-off-by: Steven Janssen<EMAIL_ADDRESS>

I had wondered that, but without knowing the limitations of each platform we run on to what is available or picking an arbitrary, possibly small, value and having to change it later would force more commits.  Would like to base it on available memory / storage on the server to determine what could/should be sent back to the requestor.

If we have an arbitrary chunk size provided by the client. The server could send back a chunk and a status code indicating more data is available if everything was not read. Then an optional argument to this command would be an offset into the file to read to complete the file.

For now this is good. will merge.


start script

This pull request is just an idea , if you want to commit then go ahead , it is your choice .
compiled chaos is good for those that have issues with golang compiler configuration , but if you update your code then you need to recompile chaos again or users will still run the old version .
The start script basically avoid the user to run on the terminal "go run CHAOS.go" , with this script all that users have to write in terminal window on CHAOS directory is : ./start
this way the user will always run the updated version of CHAOS as long as user frequently gets a git checkout , (ex: git pull) to update his version on his OS with your latest changes .
However , this start script will not solve the problem if user have his go compiler not configured or is still in an old version .
Note : if you merge this pull request , then user does not have to write execution permissions on "start" script , because script already have those permissions on github and will stay there if you merge with your git .
Basically all user have to do is to clone your git , enter chaos directory and execute ./start .

Really is more easy to users run ./start.
But i will keep the compiled version of CHAOS on the directory, and update it frequently when code was changed. To user run ./CHAOS.

Hi, i removed the compiled version, 'cause someone open a issue. The problem was caused because even running the compiled version, it is necessary have golang package installed to compile the code.
If you want, send me again a pull request with start file. Or i will create the file start.


Miner not paying out since roughly 2.27.5

This specifically relates to public Nadeko, as I'm not familiar with the method required to set it up on my install.
Had two reports come in today (and verified myself) that the miner has stopped paying out. One of the two reports says that there hasn't been a payment in a few days (and their payout value is non-0 so it seems it's been a single cached session since then). Roughly coincides with the database cleanout or the update immediately prior.

@.@ i'll look into it one of these days.


New Showcase Site (Spong Construction)

http://spongconstruction.com/

Send us an email instead at<EMAIL_ADDRESS>


Updating bind-mounts.md

Adding new info to clarify --mount vs -v. Showing that type=volume creates the endpoint for the user.
Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit eedfb96233a61c04131ba434e9571cd815e19649
https://deploy-preview-9293--docsdocker.netlify.com

Thanks for your feedback. Unfortunately, since this page talks specifically about bind mounts, we're actually referring to the specific differences between the --v flag and the bind-type mount (--mount type=bind). We will work on clarifying this to prevent any more confusion.


Error when deploying 3rd Party tools in an private subnet on Azure

I would like to know if this script can be used to deploy Viya4 on an internal network.
I tried to push the helm chart of third party tools such as nginx ingress or cert-manager to my own ACR and then specify INGRESS_NGINX_CHART_URL as the OCI URL of my ACR repository.
But I got this error: "Error: looks like "oci://xxx.azurecr.io/helm/" is not a valid chart repository or cannot be reached: object required"
I want to know if this script support using OCI protocol, if not, is there any other way to deploy these third party components?
Thank you!

Looks like there have been a number of issues with ACR as a helm OCI repository:  https://github.com/helm/helm/issues/8761
Could be worth a shot to bump helm to latest and trying again.
If you are using the docker container, modify the Dockerfile of course... although the helm version in the Dockerfile currently is pretty recent and I wouldn't expect that to make a difference.

If you have not mirror the site exactly you can adjust these variables. This would allow you to use your own chart.

Marking as stale/inactive. If there are additional questions, please open a new Github issue.

Closing #241 as completed.


Improve colors in our pygments configuration

Our default syntax highlighting of code blocks colors inline code block text in red, which I haven't seen a lot of other projects do and is probably just a mistake.
You can see some of how this looks in our integration docs:
https://zulip.com/integrations/#nagios
though of course we use the same color scheme in-app.
We should perhaps do a look through pygments.css, fix this, and think about if there's anything else we should change.

Hello!
Just to be clear, the problem is the text being red in color for inline code blocks? If yes, what is the change expected?

yes, that's the problem.  It's possible the change is to just make use black text in inline code blocks.

Hey. I am an Outreachy applicant and wish to resolve this as my first contribution.
I went through the pygments.css file.
In order to fix the red color, I think we need to specify black for the  tag in zulip.css.
Am I on the right track?

This just needed a minor change of color in the bootstrap.css file.

Merged, thanks @Katy310!  I modified the commit message a bit to match our commit message style: 5d0960ae0445e06cb1e4b3b86d33c36ef34fbf6b

(Huge thanks for fixing this!)


Feature: :sparkles: Add Gitmoji option

This PR resolves #20
I take motivation with this PR  #69.
This PR takes a flag Gitmoji as an option to use Gitmoji on commits.

I don't know Gitmoji well, but how well has it been tested?
And is this an exhaustive list of all the possible emojis? https://gitmoji.dev
If so, curious if it could be more reliable to pass it in to the prompt and ask it to pick the appropriate emoji from the list.

It would be highly desirable for this GitHub pull request to be merged subsequent to the conventional commits, in order to obtain an output similar to the example below:
✨ feat: remove Link.js test file

This commit removes the `Link.js` file from the `Tests` directory. The file contained a React component for rendering links with hover behavior, which is no longer needed and has been replaced by a different implementation.

Raycast also uses it: https://www.raycast.com/krzysztofzuraw/conventional-comments that's so great. It's what I usually use and would like to have in aicommits. 😌

Quick question... Is this repo still maintained? If not anymore... @Th3Kr4t3 Can you rebase and merge the new conflicts, so that we can use your fork?
Thank you very much!

Quick question @Nutlope is this repo still maintained? If not @Th3Kr4t3 can you rebase the conflicts and merge in the new changes so that we can at least use your fork of the project?
Thank you very much!

@Eclextic If conflicts are cleaned up, I can merge this!

@Eclextic If conflicts are cleaned up, I can merge this!

Very cool! Thank you!


David status tweak

Make badge status image more prominent on /projects/# page
Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

[Current coverage][cc-pull] is 98.29%

Merging [#425][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #425   diff @@
==========================================
  Files            37         37
  Lines           878        878
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            863        863
  Misses           15         15
  Partials          0          0

Powered by Codecov. Last updated by [cce1bd4...d4680c3][cc-compare]
[cc-base-branch]: https://codecov.io/gh/linuxfoundation/cii-best-practices-badge/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/linuxfoundation/cii-best-practices-badge/compare/cce1bd4815f75995212aa5c2e5e59a47da217df0...d4680c34575f861a5134b4752d0481139c793aa0
[cc-pull]: https://codecov.io/gh/linuxfoundation/cii-best-practices-badge/pull/425?src=pr

No complaints?

I would change "Here are the details:" to "Here is how to embed it:". I would also move the markdown above the HTML, given Github's popularity.
Otherwise, looks good.


Fix to #1767 - Support GreaterThan LessThan etc for string comparisons

Added support for string.Compare(string, string) method, which translates to:
CASE WHEN (strA = strB) THEN 0 ELSE (CASE WHEN (strA > strB) THEN 1 ELSE -1 END) END
We also recognize pattern like: string.Compare(strA, strB) == 0
This translates to much simpler form: strA = strB (also works with !=, >, >=, <, <=)
Providers need to opt-in to the sting order comparability in order for those optimizations to take effect.

@anpete

@anpete @divega updated with CR feedback

@anpete pushed an updated version, please take a look

@anpete @divega  new version up design has been considerably changed from previous iterations, please take a look

@anpete new version is up - applied recent CR feedback

:shipit:


Error getting reflective information for class org.eclipse.jetty.server.handler.IdleTimeoutHandler$1

Right after i add the dependency in the pom.xml and try to deploy on wildfly, i get this error
"Error getting reflective information for class org.eclipse.jetty.server.handler.IdleTimeoutHandler$1 with ClassLoader ModuleClassLoader for Module "deployment.test.war:main" from Service Module Loader"
Should i be manually adding any other dependencies? Tried adding this dependency
**<!-- https://mvnrepository.com/artifact/org.eclipse.jetty.server/source -->
<dependency>
  <groupId>org.eclipse.jetty.server</groupId>
  <artifactId>source</artifactId>
  <version>8.1.3</version>
</dependency>**

but maven couldn't find any such dependency.

Hi! Can you confirm your build settings for the war file?
I don't know much about wildfly, but I'm taking a look at this stackoverflow thread which suggests that this error can come from not using Java 1.8.


Calling discard() after mutations throws the error: "Transaction has been aborted, please retry." (Code 10)

Hello!
I think the client has a strange behavior when we call discard() after some mutations: it throws the following error : Transaction has been aborted. Please retry. I don't think it is useful, because if I call this method, it's precisely because I want to abort the transaction (and didn't call commit())...
In this case, I noticed that the error object has an additionnal property code with the value 10, and the following is false: e == dgraph.ERR_ABORTED.
Although the error message is the same, the error thrown when a conflict occurs during a transaction doesn't have this property code, and we can assert that: e == dgraph.ERR_ABORTED.
In my project, I currently monkey-patch the library the following way...
// Change behavior of discard.
// When calling discard() after mutations, it throws the error "10 ABORTED: Transaction has been aborted. Please retry.";
const _discard = Txn.prototype.discard;
Txn.prototype.discard = async function() {
    try {
        await _discard.apply(this, arguments);
    } catch (e) {
        if (e.code != 10) throw e;
    }
};

It is annoying because, usually, the call to discard() occurs in a finally block, so the error is not handled properly.
What do you think about this issue? Is this a desired behavior?
Thanks in advance for your answers. :)

@AlexandreDaSilva thank you for reporting this issue and taking your time to investigate it further.
It does look like a bug - i will try to reproduce it locally and if it's still happening will definitely fix it.
I suspect this is caused by another write transaction that has been committed before discard() and made the one being discarded a conflict. But server code to check for transaction conflicts is probably executed before the check of whether we want to commit or discard, resulting in an unnecessary error.
But that's a wild guess, will spend more time on it.


In source mode, add the iframe, disappeared after return

In source mode, add the iframe, disappeared after return.
in Ckeditor website ,that demo is not the problem

I Know。In the outer plus "< p > < / p >"

Hello, has this been solved? I have the same issue.


Cannot find 'process_supply_day' in test data

The column MFG_ORDERS.process_supply_day being defined and used in /app/test/Test_App_Locally.sql#L31C3-L31C21) and /app/src/libraries/streamlit.py#L17 does not exist in the test data CSV

My mistake, it is there, just need to specify the field separator correctly. closing the issue.


Connection failed. Not found

D/TwilioVoicePlugin( 6779): Connect failure
E/TwilioVoicePlugin( 6779): Call Error: 31404, Not Found
I am trying to call a physical number, and I am using the correct access token but don't know why I am facing this error.

I think this should be properly configured in a server, have you managed to call a user using the example native apps from twilio?

Please see #28

Closing due top lack of responses, feedback or activity.


Integrate Minimap with Camunda Modeler

Decide, whether we include the Minimap (bpmn-io/bpmn-js#535) with the Modeler.

Since the minimap can be toggled and many users might otherwise not know about it or would be too lazy to download the plugin I would include it. If people complain we can still remove it.


tests generated by copilot

Pull Request Test Coverage Report for Build 1501
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+4.7%) to 89.168%

Totals

Change from base Build 1500:
4.7%

Covered Lines:
2733

Relevant Lines:
3065

💛  - Coveralls


How to validate with nested  struct ?

I'm sorry but I don't get the example, that doesn't work, or at least I take it wrong.
If I take the basic struct
type User struct {     Id                  int64           json:"id"	Email               string         json:"email"	Detail              UserDetail     json:"detail"`
}
type UserDetail struct {
Description     string  json:"description"
Referer         int64   json:"referer"
}
Here's the JSON that is posted :{
"email"<EMAIL_ADDRESS>"detail": {
"referer":97
}
}`
If I want to apply a rule to the referer field, how can I set that up ?
Thx

An "omitempty" config inside my struct was causing troubles for the validation phase. My bad !


RedirectScheme middleware returns bad gateway for joined X-Forwarded-Proto header

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
If Traefik is used behind a proxy server it might receive requests containing a X-Forwarded-Proto header. If there are multiple proxies involved or one of them is misbehaving it might happen that there are multiple X-Forwarded-Proto headers.
According to the HTTP/1.1 RFC

Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.

So in that case the values of the X-Forwarded-Proto might be joined together by a proxy in front of Traefik which will result in the header X-Forwarded-Proto: https, https.
In #9121 the RedirectScheme middleware got the ability to interpret that header to decide whether it should return a redirect. In those cases it doesn't behave correctly, though.
Example request using curl:
❯ curl -i https://<router> -H 'X-Forwarded-Proto: https, https'
HTTP/2 502
[...]

For requests with the space between the header values Traefik always returns status code 502 with this error in the debug logs:
'502 Bad Gateway' caused by: parse \"https://https, https://<router>/\": invalid character \" \" in host name

Note this is only possible with insecure forwarded headers enabled.
Relevant part in the code: https://github.com/traefik/traefik/blob/e54ee89330a800d509da7b11b46a6ecbb331e791/pkg/middlewares/redirect/redirect_scheme.go
What did you see instead?
Traefik returns a response with status code 502
What version of Traefik are you using?
2.9.5, problem was introduced in 2.7.2 by #9121
What is your environment & configuration?
relevant CLI args
--entrypoints.http.address=:8000/tcp
--entrypoints.http.forwardedheaders.insecure=true

middleware configuration:
redirectScheme:
  permanent: true
  scheme: https

ingressroute (but also works with ingress or other kinds of configuration):
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: httpbin-with-middleware
spec:
  entryPoints:
  - http
  - https
  routes:
  - kind: Rule
    match: Host(`<router>`) && PathPrefix(`/`)
    services:
    - port: 8080
      name: httpbin
    middlewares:
    - name: ingress-controller-redirect-to-https@kubernetescrd

If applicable, please paste the log output in DEBUG level
No response

Hello,
the RFC says the values should be separated by a comma, the space between the comma and the value is not allowed by the RFC.

Thanks for the fast response.
Without the space the behaviour is broken as well, though:
❯ curl -i https://<router> -H 'X-Forwarded-Proto: https,https'
HTTP/2 301
location: https://https,https://<router>

In the case of an illegal request header, wouldn't 400 Bad Request be the correct response?

X-Forwarded-Proto is a mono-valued header.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto
But the 502 is not expected.


Some of Rustic's Herbs do not want to harvest on right click

MC 1.12.1
Forge <IP_ADDRESS>.2467
SimpleHarvest 1.12-1.2.4-16
Rustic 0.4.1
harvest_config.json
4 of Rustic's herbs work correctly (Cloudsbluff, Core Root, Marsh Mallow, and Ginseng). The other 8 (Horsetail, Deathstalk Mushroom, Cohosh, Chamomile, Blood Orchid, Aloe Vera, Mooncap Mushroom, and Wind Thistle) do not work. Every other crop I've added has worked correctly. I'm not sure what's wrong here. Breaking the herbs work normally, and as far as I can see, they're all implemented the same, so I'm at a loss.

I'll take a look when I get home. As a guess, I'll say the drops may not contain an IPlantable.

Thanks.

I looked and this seems to be an improper implementation of the herbs on Rustic's side. From what I'm seeing in the source, the items don't actually ever get registered, so the crop tries to drop minecraft:air, which is obviously not an IPlantable.
On another note, I will be pushing a new update that makes finalBlock optional and will default to the same block with a meta of 0. So your JSON length can be cut in half.

Thanks for the help.


Write HMM popularity blog post

The wonderful symbiosis of hidden Markov models and survey data 🤩

This is now ready for review @rlouf 🥳 Let me know if you have any questions

It's great! I see you kept some of my jokes :sweat_smile: A couple of remarks:

Not sure if showing p_disapprove on the first figure is really informative since we do not use this information. It's also redundant with No answer. Since you mention briefly No answer I would only keep this one.
"For Chirac's term, it seems like the difference stems from the polling method: face-to-face approval rates seem to be much lower" -> see figure below.
Typo: "undertand the code."
This mistake comes from me: in the model, \mu is the latent popularity, p is the popularity we can estimate from this poll.
Name of functions and distributions should be like \operatorname{Binomial}, text like pollsters in \text{}
"much more variation in the data that a Binomial distribution expects" -> "much more variation in the data than a Binomial distribution can account for"
"(yeah, I'm weird sometimes)" --> TRUTH
The ZeroSum also makes a lot of sense for house effects, maybe add a sentence about that?

Thanks @rlouf, just pushed the changes!


Opening a file with "ctrl/cmd p" slow after restart

After a restart of VS Code opening a file with "ctrl/cmd p" takes long, as the program has to finish the find in the background.
As we are using VS Code with a remote directory mounted via sshfs we have to restart Code every day and this leads to annoying waiting times in the morning. It should be possible to use the file list from the find before the restart as usually nothing has changed since then.

Tracking with #15382


bump kubernetes on master

This is mainly to prevent regressions by ensuring the master branch is up to date. For now I've called the planet release 5.6.0 for tracking master.

This PR will be obsoleted by https://github.com/gravitational/gravity/pull/372 which upgrades Kubernetes to 1.14.1.


Restructure Cog configuration options for base image selection

Related to https://github.com/replicate/cog/pull/1205#issuecomment-1634961977
As proposed, the changes in #1205 would have the following top-level config fields (among others):

gpu
cuda
cudnn
use_cuda_base_image

Although they're at the same top-level of cog.yaml, they interact hierarchically:

cuda and cudnn are used to specify the CUDA base image
...but those are ignored if use_cuda_base_image is false
...but that's moot if gpu is false

(And if we supported a custom base image, that could invalidate all of those settings)
A better solution would express these dependencies in the config structure itself. As we saw in #1010, it's possible to support advanced features in progressive way that doesn't compromise simple syntax.
Here's a rough sketch of what that might look like:

At the top level, the user has the option to specify whether to use a specific base image or to have Cog decide

If we let Cog decide, the next option down is whether to use CUDA base image or not

If we choose CUDA base image, then we allow user to override CUDA and cuDNN versions.

Not at all committed to this spelling, but maybe something like:
base: nil # default, implied by omission, Cog automatically chooses base image (python/*-slim)

base: <custom/image> # user-provided override

base:
  cuda: 11.8 # use CUDA base image
  cudnn: 8.6

We could introduce this as a minor revision to the current cog.yaml schema, deprecating but still supporting the aforementioned GPU-related fields.
Thoughts, @andreasjansson, @bfirsh, @technillogue?

Oooh, interesting. Custom images could be a can of worms, as Andreas hints. I'll let this percolate. :)
To paint a bike shed, if we do want to go in this direction: "base" is a new term, I think. In Docker-land, it's typically "from" (in Dockerfile) or "image" (in docker-compose.yaml, and other places). One could argue we want to intentionally distance ourselves from Docker, though.

@bfirsh  what about parent ?


[bug] Message: 'An unexpected error occurred! Failed to authenticate!

Description
I have installed guardrails using the pip install guardrails-ai command from the repo. After that, I entered guardrails configure  command mentioned in the repo. I created the credentials on https://hub.guardrailsai.com/tokens website. When I enter the client ID and client key in the cmd or pycharm terminal, I get the following error:
    logger.error("An unexpected error occurred!", e)
Message: 'An unexpected error occurred!'
Arguments: (ValueError('not enough values to unpack (expected 2, got 1)'),)
2024-03-11 19:53:18 DESKTOP-L4C99RG guardrails-cli[11244] ERROR Failed to authenticate!
2024-03-11 19:53:18 DESKTOP-L4C99RG guardrails-cli[11244] ERROR
            Check that your Client ID and Client secret are correct and try again.

            If you don't have your token credentials you can find them here:

            https://hub.guardrailsai.com/tokens

To Reproduce
Steps to reproduce the behavior:

Install guardrails version 0.4.1
Attempt to configure the credentials using the client ID and token from https://hub.guardrailsai.com/tokens.

Expected behavior
Guardrails should be configured so I can install validators from the hub.
Library version:
Version (e.g. 0.4.1)
Additional context

We're already looking into this and have a PR out for the same @Abdullahw72. Thank you for opening the issue!

@thekaranacharya Thanks for the quick reply. Please if possible can you ping this thread when the issue is resolved? I am looking to create a PoC using this amazing package ASAP! :) Thanks for all the help!

@Abdullahw72 yes absolutely!

Any update on this? Do we know when can we expect a fix? @ShreyaR @thekaranacharya

Hello @Abdullahw72 , we're still working on the issue. This seems like a Windows-specific issue, that multiple users are facing. Curious to know - do you use a Windows machine? This error is not present on Mac or Linux. Appreciate your patience.

@thekaranacharya Yes, I am on Windows and facing the issue so it looks like you are correct about that! Do let me know if there is anything I can do help out in fixing it :)

Hi @Abdullahw72 we merged a first draft for a fix yesterday.  If you are willing, could you try installing from our main branch in a new/fresh environment and see if the problem persists?
pip install "git+https://github.com/guardrails-ai/guardrails.git@main"

@Abdullahw72 thanks for the update!  Someone else just reported the same issue earlier this morning here: https://github.com/guardrails-ai/guardrails/issues/648
We're looking into it.  It's likely caused by another idiosyncrasy of the operating system.  Since we have a dedicated issue for this (#648) I'm going to close this issue in favor of that one.
Thanks again for your patience and willingness to help us test!

Hello @Abdullahw72 , we're still working on the issue. This seems like a Windows-specific issue, that multiple users are facing. Curious to know - do you use a Windows machine? This error is not present on Mac or Linux. Appreciate your patience.

The same problem is with mac too.

The same error occurs ubunutu too.

@Dilshan1997 we're investigating this right now -- will update asap!

@Dilshan1997 FYI -- tracking this issue over at #799

Update -- issue resolved now!

okay @ShreyaR, I will check and let you know


refactor: Change parameters format in genesis.json

Context
Fixes #4813
Solution
Changes format of genesis.json from (full format):
{
  ...
  "parameters": [
    {
      "Sumeragi": {
        "BlockTimeMs": 2000
      }
    },
    {
      "Sumeragi": {
        "CommitTimeMs": 4000
      }
    },
    ...
    {
      "Transaction": {
        "MaxInstructions": 4096
      }
    },
    ...

to (full format):
{
  ...
  "parameters": {
    "sumeragi": {
      "block_time_ms": 2000,
      "commit_time_ms": 4000,
      ...
    },
    "transaction": {
      "max_instructions": 4096,
      ...
    },
    ...

Migration Guide (optional)

kagami genesis generate will generate genesis in the new format. Custom genesis generator tools should be changed to new format.
Note that schema.json has type entry RawGenesisTransaction corresponding to genesis.json file

Review notes (optional)
Checklist

[ ] I've read CONTRIBUTING.md.
[ ] (optional) I've written unit tests for the code changes.
[ ] All review comments have been resolved.

@BAStos525 @timofeevmd format of parameters in genesis.json has changed. Please see PR description for details of the new format.


Fixed wrong page title for Dependency Convergence

Check page title here:
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

What was the reason to close this?

sorry, this was automatically closed when migrating to Git and deleting old trunk branch
reopening

merged in https://github.com/apache/maven-enforcer/commit/a7b656d2b60fb9cf316090cb3474e6477cff1849
thank you


CVE-2023-7272 in org.eclipse.parsson 1.1.7

Criticality:
high (8.7)
CVE-Link or steps to reproduce:
https://nvd.nist.gov/vuln/detail/cve-2023-7272
https://ossindex.sonatype.org/vulnerability/CVE-2023-7272?component-type=maven&component-name=org.glassfish%2Fjavax.json&utm_source=ossindex-client&utm_medium=integration&utm_content=1.7.0
Dependency
https://github.com/devonfw/IDEasy/blob/2966a61ee492d58798b7bc82bb790e0c3b311114/cli/pom.xml#L38-L42

Problem: currently we have the latest version of that artifact in use
https://repo1.maven.org/maven2/org/eclipse/parsson/parsson/
so we have to wait until a security fix of parson is release so that we can update to that version.


Add --device-map flag to allow remapping DeviceIDs

What does this PR change? What problem does it solve?
When creating backups from ZFS or btrfs snapshots, each snapshot will have a different DeviceID. This causes restic to upload the directory structure for each backup, even if nothing has changed. To solve this, this PR adds the --device-map flag which will allow users to map different device id's to the same logical device id.

The idea is that users can figure out what device ID their snapshot currently points to, (e.g. with stat -c '%d'
and then re-map that to a virtual device ID that is consistent across backups.
For example, if there's a btrfs snapshot mounted at /home/.snapshots/123/snapshot/, then you could do something like this:
device_id=$(stat -c '%d' /home/.snapshots/123/snapshot)
proot -b /home/.snapshots/123/snapshot:/home
restic backup --device-map "$device_id:42" /home

Was the change previously discussed in an issue or on the forum?
There is a decent amount of discussion on the linked issue. The larger issue here is that there are no guarantees anyways that the DeviceID is stable, and if it should be relied upon. One proposed idea was to implement an -ignore-deviceid flag, similar to the other ignore flags. However, given that the DeviceId is used to determine if symlinks span across different filesystems, this ended up not being a trivial change to implement.

Closes #3041
Checklist

[x] I have read the contribution guidelines.
[x] I have enabled maintainer edits.
[ ] I have added tests for all code changes.
[ ] I have added documentation for relevant changes (in the manual).
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
[x] I have run gofmt on the code in all commits.
[x] All commit messages are formatted in the same style as the other commits in the repo.
[] I'm done! This pull request is ready for review.

Why not let restic automatically assign pseudo-device ids as suggested in https://github.com/restic/restic/issues/3041#issuecomment-939349951 ? As rawtaz and I have commented (see e.g. https://github.com/restic/restic/issues/3041#issuecomment-939525912 ) --device-map looks like it requires rather a lot of setup to work.

Hi @MichaelEischer, thanks for taking a look. I'd be happy to implement an automatic mapping algorithm, but I'm not sure how to go about it.
Consider a scenario with 4 files, spread across two devices:
/device1/a.txt
/device1/b.txt
/device2/c.txt
/device2/d.txt

and let's say that for the first backup, device1 has a DeviceID of 17, and device2 has a DeviceID of 18.
For the second run let's say Device1 has a DeviceID of 81 and Device2 has a DeviceID of 82
The question becomes: How do we map device1 and device2 to pseudo-ids which are consistent across runs?
Let's say you do something like hash the path, or the inode. So we hash /device1/a.txt and let's say that hashes to 3. So we have a pseudo-map that says "device 17 maps to pseudo 3". Now when we see /device1/b.txt, the mapping already exists so we can use the existing value. c.txt is missing a mapping, so you would hash it and then do something like "device 18 maps to pseudo 4"
But the problem with this approach is it isn't stable across backups, unless enumeration happens in the same order. For example, on the next backup, let's say that instead of backing up a.txt, the enumeration finds /device1/b.txt first (or maybe you deleted a.txt).
Now, the algorithm would see that there is no device mapping for ID 81, and so it would hash /device1/b.txt. But now this is a different file/inode so let's say that maps to pseudo id 11. And now we haven't solved anything because the pseudo-id's are not consistent across runs.
Some ideas I considered, but with obvious flaws:

Find some way to do enumeration in-order of devices (I don't see how you can enforce this with hard links)
Poke into the guts of the filesystem to get the mappings (e.g. look at /proc/mounts) and build a hash off the base mount path, rather than the file
For each file, try to get it's parent, (and keep getting its parent), until the DeviceID changes. Use that folder path/inode as the input for the hash algorithm

The last approach seems most reasonable to me but also fairly involved. I don't know enough about all the nuances of file systems (including network drives) to know what gotcha's I'd run into trying to traverse up parent directories.
The benefit of the current approach is it's very iterative (code-wise) and results in a small diff with consistent, repeatable behavior. The last approach would involve a much larger diff and would be more likely to have a tail of "it's not stable in this configuration" etc.
Happy to hack on ideas more, once we have an idea of how the algorithm should work.

Thinking about this some more, it looks like findmnt gives me the set of device ID information needed to make a stable lookup. However at that point, I might as well just implement -use-fs-snapshot and be done with it. I'll think on this some more

Is this issue specific to Linux? I'm wondering how many systems have the issue but don't have findmnt.

I am using ZFS snapshots with restic and am affected by issue 3041. With the --device-map flag my strategy for using it would be to assign pseudo device IDs based on the mount point. These are very stable for my use case.
My experiments show that everything else is stable except the inode of the directory of the mountpoint.
#!/bin/bash
for m in $(findmnt -R -T . --json | jq --raw-output '.filesystems[0].children[].target') ; do
  SRCDEV=$(stat --format "%Ld" $m)
  DEVHASH=$(echo ${m//$(pwd)/} | b2sum --length=64 | cut -f1 -d" " | tr a-f A-F)
  PSEUDODEV=$(echo "obase=10; ibase=16; ${DEVHASH}" | bc)
  echo --device-map ${SRCDEV}:${PSEUDODEV}
done

But the problem with this approach is it isn't stable across backups, unless enumeration happens in the same order. For example, on the next backup, let's say that instead of backing up a.txt, the enumeration finds /device1/b.txt first (or maybe you deleted a.txt).

The backup sorts filenames before traversing a folder. Thus the traversal order is stable.

For example, if you hard link /device1/folderA into /device2/folderA, then iyou would run into the same issue depending on if the backup code sees /device1/a.txt or /device2/folderA/c.txt.

Hardlinks cannot point across devices. Or is there some subvolume related trickery that avoids that limitation?
The archiver component already traverses the filesystem starting from the root directory /. So we'd just have to call stat before entering a directory afterwards to detect when the mountpoint has changed.

Hardlinks cannot point across devices. Or is there some subvolume related trickery that avoids that limitation?

Although hardlinks cannot be made across devices, bind mounts can be made at different points in the filesystem. The bind mounts all share the same device ID.
With the traversal order being stable, bind mounts don't seem like an issue though. The mount that is seen first would be the path used for the pseudo identifier for the device. If this path is hashed in some way to produce the identifier it wouldn't matter how many other devices were seen before this device.

Hey, I've been successfully using this patch in unattended backups, though, on a filesystem without any bind mounts in it.
Rebasing the patch for new releases becomes increasingly hard, though, as the gap between the source tree and the patch widens.
May I ask for a review and merge, if possible?
Thanks!

As discussed in #3041 we want to have a solution that just works, without having users manually map device ids. That is the PR is just there as a temporary workaround, but is unlikely to get merged.

As discussed in #3041 we want to have a solution that just works, without having users manually map device ids. That is the PR is just there as a temporary workaround, but is unlikely to get merged.

I'm going to close this PR out. My personal opinion is that in the search of a perfect solution, we've sacrificed a good enough one.  This issue has been open for 3 years now. It's frustrating that a low-risk, opt-in fix wasn't able to make it over the line

There's now https://github.com/restic/restic/pull/4006 .


add scroll to top button

add scroll to top botton in main gradients page.

use relevant material ui or react-icons.
button position should be - bottom right.

hi @singhnitin77  please assign this to me

Hey @najeebkp can you assign me?


Update README.md

What is this Python project?
https://github.com/Dicklesworthstone/swiss_army_llama
The Swiss Army Llama is a comprehensive toolkit for working with local Large Language Models (LLMs). It uses FastAPI to provide REST endpoints for a variety of tasks, including text embeddings, completions, semantic similarity measurements, and more. It supports a wide range of document types, including those requiring OCR, and audio files for transcription. Embeddings are cached in SQLite for efficiency, and RAM Disks are used for quick loading of multiple LLMs. The toolkit is accessible via a Swagger UI and integrates with various technologies like FAISS for semantic search and the Fast Vector Similarity library for advanced similarity measures.
What's the difference between this Python project and similar ones?

FastAPI Integration: Swiss Army Llama is fully integrated with FastAPI, providing a Swagger page for easy access and interaction with its REST API, a feature not commonly found in similar projects.
Comprehensive Caching: The project implements automatic caching for all processes, significantly enhancing efficiency and reducing redundant computations. This level of automatic caching is not standard in similar tools.
RAM Disk Utilization: It uniquely uses RAM Disk to accelerate the loading of models, providing a substantial speed advantage in accessing and using various LLMs.
Broad File Format Support with Textract: The integration with Textract allows the Swiss Army Llama to handle a wide array of file formats, far exceeding the capabilities of similar projects which often have limited file format support.
Integration with Whisper: The project is integrated with OpenAI's Whisper model for advanced audio transcription, a feature that is not typically included in similar LLM toolkits.
BNF Grammar Tools: It includes specialized tools for working with Backus-Naur Form (BNF) grammars, offering unique capabilities in generating structured LLM outputs based on specific grammar rules.
Support for Token-Level Embeddings: In addition to standard embeddings, Swiss Army Llama supports token-level embeddings, providing more nuanced data representation and analysis. This level of detail in embeddings is not commonly available in similar projects.

Features:
Versatile File Processing: Supports an extensive array of file types including PDFs, Word documents, images, and audio files, with advanced text preprocessing and OCR capabilities.
Comprehensive Embedding Features: Offers both fixed-sized and token-level embeddings, with the unique introduction of combined feature vectors for comparing strings of unequal length.
Advanced Semantic Search: Combines FAISS vector searching with sophisticated similarity measures like spearman_rho, kendall_tau, and jensen_shannon_similarity, enabling nuanced text comparisons.
Efficient Caching and RAM Disk Usage: Implements efficient caching in SQLite and optional RAM Disk usage for faster model loading and execution.
Comprehensive Logging and Real-Time Monitoring: Features a real-time log file viewer in the browser, and uses Redis for efficient request handling and logging.
Interactive and User-Friendly Interface: Integrates with Swagger UI for easy access and management of large result sets, making it user-friendly and easily integrable into applications.
Customizable and Scalable: Built on FastAPI, it is highly scalable and customizable with configurable settings for response formats and parallel inference.
Multiple Model and Measure Support: Accommodates a variety of models and measures, providing flexibility and customization according to user needs.
Specialized Grammar-Enforced Text Completions: Offers the ability to generate multiple text completions with specified grammar, enhancing structured LLM output.

Awesome!


tensorflow on RISCV64

Hi ,
when can we expect tensorflow on riscv plateform ,actually you did not provided  riscv support in tensorflow so please try give riscv support ,Any reply will be highly appriciated.

i can't answer your question
I don't understand the intent of your question.


Supplying host tag when submitting a metric results in DD_TAGS specified tags to not be attached

Output of the info page (if this is a bug)
Getting the status from the agent.

===============
Agent (v7.17.0)
===============

  Status date: 2020-08-14 23:14:47.164554 UTC
  Agent start: 2020-08-05 23:14:40.003844 UTC
  Pid: 352
  Go Version: go1.12.9
  Python Version: 3.7.6
  Build arch: amd64
  Check Runners: 4
  Log Level: debug

  Paths
  =====
    Config File: /etc/datadog-agent/datadog.yaml
    conf.d: /etc/datadog-agent/conf.d
    checks.d: /etc/datadog-agent/checks.d

  Clocks
  ======
    NTP offset: 1.022ms
    System UTC time: 2020-08-14 23:14:47.164554 UTC

  Host Info
  =========
    bootTime: 2020-05-02 03:04:29.000000 UTC
    kernelVersion: 4.4.0-1101-aws
    os: linux
    platform: debian
    platformFamily: debian
    platformVersion: bullseye/sid
    procs: 70
    uptime: 2300h10m16s
    virtualizationRole: guest
    virtualizationSystem: xen

  Hostnames
  =========
    ec2-hostname: ip-10-10-9-62.ec2.internal
    host_aliases: [ip-10-10-9-62.ec2.internal]
    hostname: ip-10-10-9-62.ec2.internal
    instance-id: i-0418b6cae4b076697
    socket-fqdn: dd-agent-22tm6
    socket-hostname: dd-agent-22tm6
    host tags:
      cluster_type:kubernetes
      kubernetescluster:sandbox.k8s.centrio.com
      cluster_name:sandbox.k8s.centrio.com
      environment:sandbox
      kube_node_role:node
      kube_node_role:core-node
    hostname provider: configuration

  Metadata
  ========
    cloud_provider: AWS
    hostname_source: configuration

=========
Collector
=========

  Running Checks
  ==============

    cpu
    ---
      Instance ID: cpu [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/cpu.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 6, Total: 311,034
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s

    disk (2.6.0)
    ------------
      Instance ID: disk:e5dffb8bef24336f [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/disk.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 284, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 1.522s

    docker
    ------
      Instance ID: docker [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/docker.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 512, Total: 1 M
      Events: Last Run: 0, Total: 42
      Service Checks: Last Run: 1, Total: 51,840
      Average Execution Time : 79ms

    file_handle
    -----------
      Instance ID: file_handle [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/file_handle.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 5, Total: 259,200
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s

    fluentd (1.5.0)
    ---------------
      Instance ID: fluentd:a7ad8395a235730 [OK]
      Configuration Source: kubelet:docker://128d1e53aeee0ece0469522627b0bea5c010e3bf5d21c64ee1187a18107d4971
      Total Runs: 23,765
      Metric Samples: Last Run: 5, Total: 118,825
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 23,765
      Average Execution Time : 61ms

    http_check (4.6.3)
    ------------------
      Instance ID: http_check:etcd:555f04d8819efe8d [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/http_check.yaml
      Total Runs: 51,840
      Metric Samples: Last Run: 5, Total: 259,200
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 103,680
      Average Execution Time : 144ms

      Instance ID: http_check:registry:70f468b5e2e82a72 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/http_check.yaml
      Total Runs: 51,841
      Metric Samples: Last Run: 5, Total: 259,205
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 103,682
      Average Execution Time : 212ms

      Instance ID: http_check:vault:78f6fdb97c23bf67 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/http_check.yaml
      Total Runs: 51,840
      Metric Samples: Last Run: 5, Total: 259,200
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 2, Total: 103,680
      Average Execution Time : 214ms

    io
    --
      Instance ID: io [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/io.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 104, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 1ms

    kubelet (3.5.1)
    ---------------
      Instance ID: kubelet:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/kubelet.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 723, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 4, Total: 207,360
      Average Execution Time : 1.62s

    kubernetes_state (5.1.0)
    ------------------------
      Instance ID: kubernetes_state:da1c302ce5bb9929 [OK]
      Configuration Source: kubelet:docker://2cc52cf536041fe466bcc9b641af9969c6f30a5f043f89329edc08294bbda95f
      Total Runs: 5,587
      Metric Samples: Last Run: 79,593, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 3,332, Total: 1 M
      Average Execution Time : 11.857s

    load
    ----
      Instance ID: load [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/load.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 6, Total: 311,040
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s

    memory
    ------
      Instance ID: memory [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/memory.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 17, Total: 881,280
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s

    network (1.14.0)
    ----------------
      Instance ID: network:e0204ad63d43c949 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/network.d/conf.yaml.default
      Total Runs: 51,840
      Metric Samples: Last Run: 31, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 277ms

    nginx (3.6.0)
    -------------
      Instance ID: nginx:bc19242fd3bdbe8d [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/nginx.yaml
      Total Runs: 51,840
      Metric Samples: Last Run: 7, Total: 362,873
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 51,840
      Average Execution Time : 74ms
      metadata:
        version.major: 1
        version.minor: 15
        version.patch: 8
        version.raw: 1.15.8
        version.scheme: semver

    ntp
    ---
      Instance ID: ntp:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/ntp.d/conf.yaml.default
      Total Runs: 865
      Metric Samples: Last Run: 1, Total: 865
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 865
      Average Execution Time : 692ms

    openmetrics (1.4.0)
    -------------------
      Instance ID: openmetrics:kubernetes_state:2818390c49ff5749 [WARNING]
      Configuration Source: kubelet:docker://2cc52cf536041fe466bcc9b641af9969c6f30a5f043f89329edc08294bbda95f
      Total Runs: 5,886
      Metric Samples: Last Run: 2,000, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 5,886
      Average Execution Time : 6.844s

      Warning: Check openmetrics exceeded limit of 2000 metrics, ignoring next ones

      Instance ID: openmetrics:node_exporter:5381bacdc75f9a42 [OK]
      Configuration Source: kubelet:docker://bb871b80035f426136eac1eecbc3df330d6c0026aa69c4628d2efd15b809fbff
      Total Runs: 51,840
      Metric Samples: Last Run: 6, Total: 311,040
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 51,840
      Average Execution Time : 231ms

    prometheus (3.2.0)
    ------------------
      Instance ID: prometheus:calico:6e2d440ca6b49c58 [OK]
      Configuration Source: kubelet:docker://5cf397ef5e81f87cbc0fc3736d633b98550c3e0916850b322afef0bd61b081a9
      Total Runs: 51,841
      Metric Samples: Last Run: 142, Total: 1 M
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 51,841
      Average Execution Time : 81ms

    tls (1.4.0)
    -----------
      Instance ID: tls:fb78d1d72f83021 [OK]
      Configuration Source: kubelet:docker://c745d8c7865cc5a83cbdacb66fd734c3cbeba9a9667b9672435d4250bcb3af59
      Total Runs: 51,840
      Metric Samples: Last Run: 2, Total: 103,680
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 4, Total: 207,360
      Average Execution Time : 110ms

    uptime
    ------
      Instance ID: uptime [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/uptime.d/conf.yaml.default
      Total Runs: 51,841
      Metric Samples: Last Run: 1, Total: 51,841
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s

========
JMXFetch
========

  Initialized checks
  ==================
    no checks

  Failed checks
  =============
    no checks

=========
Forwarder
=========

  Transactions
  ============
    CheckRunsV1: 51,840
    Dropped: 0
    DroppedOnInput: 0
    Events: 0
    HostMetadata: 0
    IntakeV1: 5,643
    Metadata: 0
    Requeued: 0
    Retried: 0
    RetryQueueSize: 0
    Series: 0
    ServiceChecks: 0
    SketchSeries: 0
    Success: 715,431
    TimeseriesV1: 51,840

  API Keys status
  ===============
    API key ending with 05c5f: API Key valid

==========
Endpoints
==========
  https://app.datadoghq.com - API Key ending with:
      - 05c5f

==========
Logs Agent
==========

  Logs Agent is not running

=========
Aggregator
=========
  Checks Metric Sample: 3.5 G
  Dogstatsd Metric Sample: 21.4 M
  Event: 43
  Events Flushed: 43
  Number Of Flushes: 51,840
  Series Flushed: 3.5 G
  Service Check: 131.8 M
  Service Checks Flushed: 131.9 M

=========
DogStatsD
=========
  Event Packets: 0
  Event Parse Errors: 0
  Metric Packets: 21.4 M
  Metric Parse Errors: 0
  Service Check Packets: 0
  Service Check Parse Errors: 0
  Udp Bytes: 490.6 M
  Udp Packet Reading Errors: 0
  Udp Packets: 6.1 M
  Uds Bytes: 1.1 G
  Uds Origin Detection Errors: 0
  Uds Packet Reading Errors: 0
  Uds Packets: 3 M

=====================
Datadog Cluster Agent
=====================

  - Datadog Cluster Agent endpoint detected: https://<IP_ADDRESS>:5005
  Successfully connected to the Datadog Cluster Agent.
  - Running: 1.4.0+commit.f102bd8

Describe what happened:
We tried supplying the host tag with a metric to suppress the agent from adding its own host information, since the host information is not relevant for some of our metrics.  When we did this, other tags that are specified using DD_TAGS environment variable were not attached to the metric, but our manually specified host tag was.
Describe what you expected:
Global tags specified by DD_TAGS should always be attached to a metric, regardless of what other tags are submitted.  Tag values that are explicitly submitted with a metric should take precedence over the values specified in DD_TAGS.
Steps to reproduce the issue:

Configure the agent to attach environment:sandbox using DD_TAGS
Submit host:foobar as a tag along with a metric
Observe that host:foobar tag appears in datadog, but environment:sandbox tag does not.  If host:foobar is not submitted as a tag on the metric, observe that the environment:sandbox tag will appear.

Additional environment details (Operating System, Cloud provider, etc):
I believe enough information is specified in the agent information page.  Let me know if more information would be useful.

Hey @millerick
Thanks for reaching out!
There is a simple explanation to this behavior:
Host tags are not sent along with metrics, logs nor traces. They are sent once, when the agent starts, along other host related data like the hostname.
Host tags are then reconciled on our backend thanks to... the hostname!
So, if you change the host tag on one of your custom metric or check metric, the backend will not be able to find the right host and thus, the right tags.
I hope it makes sense!
Let us know if you have further questions.

@Simwar , is there a way to omit the addition of the host tag while still having the DD_TAGS tags applied?  Context is that the tag cardinality that host tag creates for some metrics is large and is rarely used in a meaningful way for our own observability purposes, but the tags added via DD_TAGS are often times useful and low cardinality.

@Simwar , another question: if the agent makes the call once on startup, how long does the host:DD_TAGS mapping stay in the system?  I.e. if we start an agent on a host, and supply that as the host tag for a multitude of metrics, but then that host ceases to exist at some point in the future, will the original DD_TAGS eventually cease to be associated with the metrics?


[FLINK-19391][network] Moved notification during subpartition request to the requester.

What is the purpose of the change
This change avoid a deadlock on requestLock that may happen with concurrent release via input gate.
The deadlock was introduced by the alternative fix for FLINK-12510 in FLINK-19026 .
The alternative fix avoided double lock acquisition in SingleInputGate#waitAndGetNextData by moving notifyDataAvailable from ResultSubpartition#createReadView to ResultPartitionManager#createSubpartitionView, which solved the circular deadlock of FLINK-12510 by not acquiring the buffers lock of PipelinedSubpartition.
However, that fix didn't go far enough. For local channels, it is still possible to create a similar deadlock. While SingleInputGate reads from LocalInputChannel, it holds the lock inputChannelsWithData. The channel may start requesting the partition and tries to acquire requestLock.
At the same time there is an update of partition info, which acquires the requestLock and notifies the SingleInputGate, which needs to lock on inputChannelsWithData.
The solution is to first acquire the partition and release requestLock before notifying SingleInputGate.
Brief change log

Moved notification during subpartition request to the requester.
Fixes the broken SingleInputGateTest#testPartitionRequestLogic, where pollNext was a no-op.

Verifying this change
This is a bugfix for broken master cron job and is already covered by it.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Can you describe in the ticket, commit message and optionally in PR what was the deadlock scenario and how is it being addressed?

Updated all 3.


NIOCore.ChannelError.connectTimeout

Is there an existing issue for this?

[X] I have searched the existing issues

OracleNIO version
Main
Database version
19C
Operating system and version
macOS 15.0
Swift Version
.package(url: "https://github.com/lovetodream/oracle-nio.git", branch: "main"),
Describe the bug
In the new macOS the come a connection Timeout
NIOCore.ChannelError.connectTimeout(NIOCore.TimeAmount(nanoseconds:<PHONE_NUMBER>0))
Steps To Reproduce
let logger = Logger(label: "oracle-logger")
    let config = OracleConnection.Configuration(
        host: "xx",
        port: x,
        service: .serviceName("Test"),
        username: "x",
        password: "x"
    )

    let connection = try await OracleConnection.connect(
      configuration: config,
      id: 99,
      logger: logger
    )

here come the timeout

Outcome
NIOCore.ChannelError.connectTimeout(NIOCore.TimeAmount(nanoseconds:<PHONE_NUMBER>0))
Additional context
No response

Did it work with older macOS versions for you?
Are you connecting to the db in a iOS, macOS, etc. or a Server app?

yes it works with older Macos version. But now it works, I disabled the firewall in settings

Ah, that's great to hear, thanks for letting me know!

can you say me how I map a OracleRow to a struct?

This is not possible right now, but it might soon be, have a look at this #60
For now you need to do something like this:
struct User {
  var id: Int
  var name: String
  var age: Int
}
let stream = try await connection.query("SELECT id, name, age FROM users")
var users: [User] = []
for try await (id, name, age) in stream.decode((Int, String, Int).self) {
  users.append(.init(id: id, name: name, age: age))
}
print(users)

thanks i implemented this , but how i implement this if I have a lot of columns.? or i work with select *
Is there a way to make it more comfortable?

At the moment, this is the only way, even with a lot of columns. I know it is not ideal, I have noticed it myself when working with 20+ columns in my select statements. This will get a lot easier with #60.
I would advice you to never use SELECT *, even if you want to select every column, it is still slower than typing out every column. Not to mention the problems that can happen when you add more columns later and forget about a SELECT * somewhere. This advice generally applies to all relational databases and all database drivers in every language.


Update section related to downloading/uploading GHES license file

What's being changed:
"How to download the license file" is often a top concern and I'm proposing that we reflect this in the section header.
Current section header:
"Uploading a new license to GitHub Enterprise Server"
Proposed new section header:
"Downloading a new license file and uploading it to GitHub Enterprise Server"
Check off the following:

[x] I have reviewed my changes in staging (look for the latest deployment event in your pull request's timeline, then click View deployment).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@stacycarter Thanks so much for opening a PR! I'll get this triaged for review ⚡

I managed to get your branch and made the changes myself 🙂


Document Flask Debug Mode auto instr limitation

Description
Recently our customers came across unexpected behavior when using OTel Python on their Flask app to generate traces for X-Ray. This is a known current bug in OTel so we will update our public documentation for increased visibility.

LGTM - Looking for more eyes
Small Note : Do Not merge  :-)


openiscsi: 2.1.7 -> 2.1.8

Description of changes
autotools -> meson

support for make/autoconf is still in place but is deprecated

https://github.com/open-iscsi/open-iscsi/releases/tag/2.1.8

Replaces/Closes #193104
Draft, because it breaks the passthru.tests
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

This should work now, but the iscsi multipath test ist broken after #199710


MSDDetector Impementation

Implementation of a Novel Feature2D Detector. See here for more infos:
https://github.com/fedassa/msdDetector

:+1:  nice one!

Thanks for tips! :+1:

@m4nh Could you close this PR down?

Thank you!


Update changelog and config

Added

Add header to changelog config

Changed

Change old changelog entries to keepachangelog format

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


chore(header): centralized logo option

Screenshots

Two types:

Only centralized logo active:

Centralized logo and full_width active:

Checklist

[x] I've read and understood contributing guidelines;
[x] If changing UI, I've tested on most common viewports, desktop and mobile devices;

Pronto