Allow having gobject's inner structs with limited visibility

Currently it seems that the gobject structs need to be public, otherwise you get a crate-private type 'object::imp:Object' in public interface error. Is it possible to allow at least a pub(crate) visibility?

Mh, maybe I'm wrong, but I'm pretty sure you can at least set the visiblity of the entire gobject to something different than pub, e.g. this is what I'm doing in my app, I'm setting both the imp struct and the gobject itself to pub(crate) and it works just fine. But maybe there's a specific problem doing that with this macro?

You can but I didn't add that yet, the visibility of the inner struct always has to match the wrapper type

The wrapper type could always match the visibility of the inner struct, except when it's private then we'll have to force the inner to pub(super)

That still has some issues, need to map:

pub(self), pub(in self) → pub(super)
pub(super) → pub(in super::super)
pub(in super:: ...) → pub(in super::super:: ...)

Can you try now after https://github.com/jf2048/gobject/commit/ec97da1b74b2d4c6d7162b6682dd3ef93ceb6e0a and see if that lets you do it?

Yes, it works (at least with the pub(crate) visibility).


feat: valset update at least at each 2000 eth blocks

Added check if the last updated valset didn't happen at 2000 blocks and it is using the valset relay mode as minimum
The block number is stored in the gravityRelayer and updated each time a new valsetUpdateEvent event is founded in FindLatestValset
To test this, was needed to use some things like ./test/eth and ./test/scripts

closes: #283
How to test

Prerequisites: node v16.9.1 && yarn

Copy the umeed binary to test/umeed-builds/umeed-main

Enter inside test/eth and install everything

$~ yarn install

Run the script test/scripts/valset_update_2000_blocks.sh

Expected Output

Sorry for the huge delay :) I'll take a look at this, but I'll also would like to explore other alternatives and see what the Gravity Bridge orchestrator (the one written in Rust) is doing

see what the Gravity Bridge orchestrator (the one written in Rust) is doing
Good idea ;D

Codecov Report

Merging #311 (b7d75e2) into main (67c3e5f) will decrease coverage by 0.69%.
The diff coverage is 28.26%.

@@            Coverage Diff             @@
##             main     #311      +/-   ##
==========================================
- Coverage   58.56%   57.87%   -0.70%
==========================================
  Files          17       17
  Lines        2003     2039      +36
==========================================
+ Hits         1173     1180       +7
- Misses        730      756      +26
- Partials      100      103       +3

Impacted Files
Coverage Δ

orchestrator/relayer/valset_relaying.go
69.76% <0.00%> (-0.55%)
:arrow_down:

orchestrator/relayer/relayer.go
43.18% <8.69%> (-37.78%)
:arrow_down:

orchestrator/oracle_resync.go
39.49% <50.00%> (-0.24%)
:arrow_down:

orchestrator/relayer/find_latest_valset.go
72.79% <100.00%> (+0.20%)
:arrow_up:


Paper/implementation mismatch?

In practice, computing the parity of x(i) is still a heavy
operation compared to others. Hence, it can be beneficial to
delay it until it is absolutely necessary. In Algorithm 5.2, we
need to compute the parity of x(i) when r and δ(i) turn out
to be the same. However, in fact if either the interval I does
not include the left endpoint or x is not an integer, we always
conclude I ∩ 10^(−k0+1)Z is empty regardless of the parity of
x(i). Therefore, if the given rounding mode indicates that the
left endpoint is not in I, we can skip computing the parity of
x(i).

(section 5.1.6, page 21)
If I understand this correctly, the condition of the left endpoint being excluded or x not being an integer is enough to say that the intersection in question is empty, and the parity doesn't need to be checked.
However, the algorithm implementation seems to disagree:
                    if (!interval_type.include_left_endpoint() ||
                        exponent < case_fc_pm_half_lower_threshold ||
                        exponent > divisibility_check_by_5_threshold) {
                        // If the left endpoint is not included, the condition for
                        // success is z^(f) < delta^(f) (odd parity).
                        // Otherwise, the inequalities on exponent ensure that
                        // x is not an integer, so if z^(f) >= delta^(f) (even parity), we in fact
                        // have strict inequality.
                        if (!compute_mul_parity(two_fl, cache, beta).parity) {
                            goto small_divisor_case_label;
                        }
                    }
                    else {
                        auto const [xi_parity, x_is_integer] =
                            compute_mul_parity(two_fl, cache, beta);
                        if (!xi_parity && !x_is_integer) {
                            goto small_divisor_case_label;
                        }
                    }

In fact, the comments explicitly state that checking parity is required. From quick testing it seems that the code is right here.

Side note: I think that part can be simplified to something like the following pseudocode.
xi_parity = compute_mul_parity().parity
if (!xi_parity) {
    if (!include_left_endpoint) {
        goto small_divisor_case_label
    }
    // x(i) is an even number and the left endpoint is included, check if x is an integer
    if (exponent < case_fc_pm_half_lower_threshold || exponent > case_fc_pm_half_lower_threshold) {
        goto small_divisor_case_label
    }
    x_is_integer = compute_mul_parity().is_integer
    if (!x_is_integer) {
        goto small_divisor_case_label
    }
}

This matches Algorithm 5.2 (step 7) more closely.

Hmm. This is indeed weird. I don't know why I wrote it like that 😂 Probably I came up with some wrong idea, tested it, figured out I was wrong, so corrected the code but in a stupid way, and also forgot to rewrite the paper. Thanks a lot for catching this!! I'll correct it right away.

Thanks again, it's fixed now.


[RFC]: Secrets in environment variable placeholders

We've discovered that there is a need to specify which config values should be sent to the client / or which values contain secrets and should therefore only be exposed to the server-side implementation.
There are a few solutions for white-listing values for the front-end that come to mind:

indicate through a naming scheme of the key, that this value should be secret (eg. _foo)
indicate through special characters in the value (eg. double brackets [[FOO]]) that this value should be secret
use an array with white-listed keys, that will be merged automatically (to allow each preset to add their own values) to indicate which values should be forwarded to the client
use an object that holds a mapping of keys to boolean values that should be white-listed (in contrast to the previous suggestion, this would allow users to override values set by presets)
allow an object as value that contains two fields (value and expose or similar) to configure that specific field

{
  "name": "untest",
  "license": "MIT",
  "untool": {
    "_variant_1": "[SECRET]",
    "variant_2": "[[SECRET]]",
    "variant_3": "[NO_SECRET]",
    "whitelist_array": [
      "variant_3"
    ],
    "variant_4": "[NO_SECRET]",
    "whitelist_object": {
      "variant_4": true
    },
    "variant_5": {
      "value": "[NO_SECRET]",
      "expose": true
    }
  }
}

Another option would be to introduce an object (e.g. serverOnly) that would be merged and generally handled separately and that could hold the appropriate props and hidden from the client.
That being said, my personal preference would be option 1 or 2..: these appear to be most aligned with framework and ecosystem standards and conventions.

I would prefer to white-list keys that should go to the client-side instead of black-listing them (which would be kind of the case with serverOnly).
I don't like variant 2 and 5 because then a user could overwrite the default value that comes from a preset and would lose the visibility settings.
With variant 1 we would need to change our code whenever the visibility changes (or build some complicated getter/proxy stuff around it), therefore I would prefer variant 3 or 4.
I think I'm leaning more towards variant 4, because that would allow later presets / the application config to overwrite the visibility of values, but since it will always be merged it is safe by default.

I mostly agree with @ZauberNerd here. I would add though that version 4 makes it too easy to overwrite the setting and thus provides kind of a foot gun. I also right now can't think of a situation where a preset would want to change the visibility set by a previous preset.
So I'd be in favour of variant 3.
It still provides a way to change the setting, which could be applied by users and preset authors alike. So coming from a preset that looks like that…
{
  "secret": "[SUPER_SECRET]"
}

…ppl could expose the value like this…
{
  "secret": "[SUPER_SECRET]",
  "meDontCares": "<secret>",
  "whitelist_array": ["meDontCares"],
}

If we did decide to go with variant 3, we would have to deal with that array similar to mixins - and that would be breaking abstractions, unfortunately: we would be introducing knowledge about the distinction between client and server to @untool/core - and that is something it is not really supposed to know about.
I would therefore prefer going with variant 4 and implement it in @untool/webpack.

I consider this decided & done!


Feature: Binary artifacts check should allow signed binaries

Feature request: in a similar vein as #1815 Scorecard Binary Artifacts should allow signed files. See below

@randomascii commented 23 minutes ago
My github project necessarily contains five binary files that come from a Microsoft SDK. They are needed for proper operation of the project. Removing them from the repo would require getting them from somewhere else which would be less secure.
These files are all signed. The allstar project could reduce it's "false positive" rate by treating signed files separately, either not warning on them or giving a different type of warning.
Right now if I add a signed binary file to my repo the warning will be identical to the warning I get when I add an unsigned file, despite the fact that the risk level is dramatically different between the two of them. This means that I have to do manual signature checking, which is something that allstar should be doing.

sounds reasonable. @randomascii how does verification work? Could you give us some pointers how scorecard could verify it's a Microsoft-signed binary?
Also, are there conventions for the filename: .exe, .dll, others?

Good question. I don't know details of how the signatures are stored. I know that .exe and .dll files are probably the two most common file extensions that would be signed, but other file types can also be signed (.msi at least). I use sigcheck.exe from sysinternals (https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck) to verify the signatures - it says whether they are signed, and who they are signed by.
It looks like sigcheck uses CryptAcquireContext, CertGetCertificateChain, CryptCATOpen, and a couple of dozen other Win32 cryptography related functions to do the signature verification.

sounds reasonable. @randomascii how does verification work? Could you give us some pointers how you verify it's a Microsoft-signed binary?
Also, are there conventions for the filename: .exe, .dll, others?

There is lot to unpack here with validation of Signed Windows binaries without Windows https://blog.trailofbits.com/2020/05/27/verifying-windows-binaries-without-windows/
cc @woodruffw

Yep. Windows binaries are usually signed with Authenticode, which is PKCS#7 formatted with some vendor-specific tweaks.
uthenticode works, but an important caveat: it doesn't do full chain verification. It could, in theory, if someone were to reverse engineer Windows's trust store and export whatever default root certs are in it, but I haven't undertaken that task 🙂. For the time being, all uthenticode does is verify the internal consistency of the embedded certificates, the cryptographic hash, and whatever other invariants are expected that aren't predicated on the full chain.

Yep. Windows binaries are usually signed with Authenticode, which is PKCS#7 formatted with some vendor-specific tweaks.
uthenticode works, but an important caveat: it doesn't do full chain verification. It could, in theory, if someone were to reverse engineer Windows's trust store and export whatever default root certs are in it, but I haven't undertaken that task 🙂. For the time being, all uthenticode does is verify the internal consistency of the embedded certificates, the cryptographic hash, and whatever other invariants are expected that aren't predicated on the full chain.

Great! Thanks! Does uthenticode have an API that we can call from the go code?

Great! Thanks! Does uthenticode have an API that we can call from the go code?

I don't know very much about Go -- can you call C++ APIs from it? If so, then yes. Otherwise, you might need to write a small C API shim around the public C++ API and use cgo (I think that's what it's called?)

Specifically, the C++ API is currently documented here: https://trailofbits.github.io/uthenticode/

Specifically, the C++ API is currently documented here: https://trailofbits.github.io/uthenticode/

👍

Thanks @naveensrinivasan and @woodruffw I wish there was a GHA that validates these, like for Java wrapper https://github.com/ossf/scorecard/issues/2048
Maybe that'd be easier? Would @trailofbits be interested in packaging up the code into a GHA?
For root CAs, any ideas how often I don't know how often these CA keys are rotated; I assume not very often...?
/cc @di
@raghavkaul there is some structured results we could add here in terms of binary type / signature / wrapper action, etc

Maybe that'd be easier? Would @trailofbits be interested in packaging up the code into a GHA?

We have one here: https://github.com/trailofbits/winchecksec-scan
That action runs all of Winchecksec, which includes a bunch of other property tests on the binary (e.g. for ASLR, DEP, etc.).
We don't have a specific use case that would require use to break just uthenticode out into its own GitHub Action, though, and that isn't scoped in any current work we have.

For root CAs, any ideas how often I don't know how often these CA keys are rotated; I assume not very often...?

I don't have any strong numbers/statistics on this, but my understanding is that the Windows codesigning trust store gets updated somewhat frequently -- vendors are constantly being added and removed from the trusted set, and any given Windows host may or may not have the same trusted set as others (because of different Windows versions, "flavors" like consumer vs. enterprise, etc.).

Maybe that'd be easier? Would @trailofbits be interested in packaging up the code into a GHA?

We have one here: https://github.com/trailofbits/winchecksec-scan
That action runs all of Winchecksec, which includes a bunch of other property tests on the binary (e.g. for ASLR, DEP, etc.).
We don't have a specific use case that would require use to break just uthenticode out into its own GitHub Action, though, and that isn't scoped in any current work we have.

That's great. There is support for enabling authenticode on its own, so scorecard could check for the presence of this action and this argument passed. It does not solve the full chain validation. I suppose it's pretty hard to do anything beyond  what your tool already does.

For root CAs, any ideas how often I don't know how often these CA keys are rotated; I assume not very often...?

I don't have any strong numbers/statistics on this, but my understanding is that the Windows codesigning trust store gets updated somewhat frequently -- vendors are constantly being added and removed from the trusted set, and any given Windows host may or may not have the same trusted set as others (because of different Windows versions, "flavors" like consumer vs. enterprise, etc.).

Yep -- I think the best we could do is opportunistically detect the local machine's trust store (assuming it's a Windows host) and figure out how to reuse it, but that presents its own problems (both in terms of UX and user expectations, as well as increased ambiguity about the verification we're performing).

Got it. Do you know if the GitHub Windows runners have a "standard" CA store? Could we use one of the utilities shipped with Windows to perform the verification for us?

Could we use one of the utilities shipped with Windows to perform the verification for us?

Yep, I think so -- the builtin signtool or certutil should do the trick.

Brilliant, thanks for the information. Should this functionality live in the trailofbits action? It seems to be the best place, but I don't know how much work would be involved or who should do the implementation. Let us know, thanks

Brilliant, thanks for the information. Should this functionality live in the trailofbits action? It seems to be the best place, but I don't know how much work would be involved or who should do the implementation. Let us know, thanks

That action was mostly a proof-of-concept, so I'm weary of introducing too much more functionality to it 😅. It also runs on Linux with a Docker container, so retrofitting it for Windows would likely be roughly as much effort as doing things "right" from scratch (a Windows runner + using signtool directly instead of uthenticode).
I think this is probably a good candidate for a new GitHub Action, one that's constrained in domain to just a Windows runner and the tools that MS provides.

Thanks for the detailed explanation. Totally understand.
Does everyone else think the right direction is to have a separate GHA ,like the Java wrapper GHA?
Or do you think scorecard should handle it itself?
/cc @ethanent

Does everyone think the right direction is to have a separate GHA ,like the Java wrapper GHA?
👍 +1

Does everyone think the right direction is to have a separate GHA ,like the Java wrapper GHA?
Or do you think scorecard should handle it itself?

I think having Scorecard handle the checking of such binaries might too significantly expand the burden on Scorecard maintainers, but it is tempting because it doesn't require configuration on the part of repo owners being checked.
For the GHA check solution, there is some complexity that arises from figuring out which files have been verified. We could use the annotations provided by the relevant check run for the latest commit if they are in a common format.
The gradle/wrapper-validation-action, for example, uses a format that isn't extremely easy to parse.
Gradle Wrapper Validation Failed!
  See https://github.com/gradle/wrapper-validation-action#reporting-failures
✗ Found unknown Gradle Wrapper JAR files:
  3c56bb5e0c1016189ab1a7ba45b351136f2f7f5d3d53afa812c8479edf9fae30 gradle-wrapper/gradle-wrapper.jar

We could make a straightforward standard format for providing file verification results in annotations from other checks, something like...
{
  "results": [
    {
      "file": "bin/some_verified_executable.exe",
      "verified": true
    },
    {
      "file": "bin/some_tampered_executable.exe",
      "verified": false,

      // optional message
      "message": "File not signed by trusted party"
    }
  ]
}

Relevant GitHub API endpoints:
List check runs for a Git reference: /repos/{owner}/{repo}/commits/{ref}/check-runs
=> Take each check run ID and get dependencies using next endpoint.

Or do you think scorecard should handle it itself?

Actually, on the topic of the solution whereby Scorecard verifies binaries itself, I don't think it's the best because it would mean Scorecard is just verifying the files at a point in time, rather than checking that the project has a process in place for verifying the files in the future.
Because, in my opinion, that doesn't fit with the "preventative" (reducing potential for attack) philosophy of the Binary Artifacts check, I would recommend a GHA solution like I described in my previous comment.

If we create an Action, where should it leave? A new ossf repository? In scorecard repository?
What shall we call it?
Do we need a "meta" Action that contains signature verification, gradle wrapper, etc? (And the other ones we may need later)

If we create an Action, where should it leave? A new ossf repository? In scorecard repository? What shall we call it?

Probably in another ossf repo. Maybe something like "binary-verification-action"?

Do we need a "meta" Action that contains signature verification, gradle wrapper, etc? (And the other ones we may need later)

I like this idea! I think we should continue to allow a passing gradle/wrapper-validation-action to exempt gradle-wrapper.jar files, but similar verification could additionally be added to this Action (eventually) for the sake of simplicity.

Let's add this for discussion next meeting. @ethanent are you interested ^^

Not stale, I believe.


add some tests

Coverage increased (+2.0%) to 75.514% when pulling 72787c87e383efed33545b31070cfda132feaa0a on erik0704:master into 90fe8eb6fb2e4eb86459ba0a7a279039d40af82e on CS2103AUG2017-W10-B4:master.


Pin geos

Pinning geos to avoid conflicting with geos 3.5.0 in defaults.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


WIP flutter prototype

Branch for content from issues about mobile prototype.

I will just close this, we will not need this changes.


chore(api, shared-data): LLD tuning after testing

Overview

Small adjustments to all pipettes' minHeight values (all of them got a bit bigger)
1ch and 8ch pipettes tested better at 15 mm/sec (as opposed to 20 mm/sec)

Test Plan and Hands on Testing

Changelog

Review requests

Risk assessment

closing to make new branch based off internal release branch


ChildAction shoudn't reset _cacheKey for OutputCacheFilter

This wasn't raising awareness in Orchard community as the official code base does not use Child Actions (they use shapes).
Previously there is reentrancy-prevention code in OnResultExecuted to filter out Child Actions so that OnResultExecuted only gets executed once per request and only for the parent Action. However, this reentrancy-prevention code is being incorrectly placed in the try-catch block, that the finally-block can get executed more than once if parent Action includes any Child Action. This wasn't an issue until commit 117dd09f (first included in release 1.10) which resets _cacheKey in that finally-block via ReleaseCacheKeyLock. Now for every request that uses Child Actions, the finally block will be executed at least once during Child Action's OnResultExecuted, leaving the _cacheKey as null. Later after all Child Actions finish execution, the parent Action's OnResultExecuted will now see a _cacheKey of null, thus causing NRE in captureStream.Captured event handling code.

#6701


DefaultDate not working

I cannot set the default date of an input field. I am building a laravel app and if I enter a date and the validation fails, I want to persist the data that was entered. This works fine for all fields besides the date. Here is the issue in a jsfiddle https://jsfiddle.net/sj6gryd1/
Is this the proper way to preload a date?

You can do like this https://jsfiddle.net/sj6gryd1/2/
you need to use or value="..." in HTML or defaultDate: "..." in JS. But don't forget about format date!
<article>
    <input type="text"
           placeholder="Select Date.."
           class="date"
           value="06-28-1987"
           >
</article>

const fp = flatpickr(".date",{
	dateFormat: "m-d-Y"
//	,defaultDate: "06-28-1987"
});

@JuanRangel looks like you forgot to specify your dateFormat
See @MaximSavin response

@JuanRangel
I specified format and minDate, And I found that when I remove minDate, defaultDate working fine but I don't know why.
Worked Code.
<Flatpickr               placeholder="Start Date"               options={{ dateFormat: this.props?.format, defaultDate: this.props.value }} />


linuxPackages are not overridable when used in a module

Issue description
It seems like pkgs.linuxPackages are not overridable if a package is used in a module. I hit this when trying to patch TRIM support into ZFS.
Steps to reproduce
{ config, pkgs, lib, ... }: {
  nixpkgs.overlays = [ (self: super: {

    linuxPackages = super.linuxPackages // {
      zfsUnstable = (super.linuxPackages.callPackage <nixpkgs/pkgs/os-specific/linux/zfs> {}).zfsUnstable.overrideAttrs(o: {
        name = "zfs-trim-kernel";
        src = pkgs.fetchFromGitHub {
          owner = "dweeezil";
          repo = "zfs";
          rev = "ntrim2-next";
          sha256 = "0ngjrq9hyhj5whxqvmqbj9ni0icqxgd72hv1a097m96xl6r796nd";
        };
        patches = [
          (pkgs.fetchpatch {
            name = "ntrim2-patch";
            url = "https://github.com/dweeezil/zfs/compare/ntrim2-next...schuppentier:nixos-zfs.patch";
            sha256 = "0fw7skw6gsx9girxvc0c4aqibgnwakbf9r6gyvc0ccnm8z9w1pqb";
          })
        ];
      });
    };
  }) ];
}

This works (not using the module):
boot.extraModulePackages = [ pkgs.linuxPackages.zfsUnstable ];

This does not work (using the zfs module):
boot.supportedFilesystems = [ "zfs" ];

Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.29, NixOS, 18.03pre131587.b6ddb9913f2 (Impala)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.0`
 - channels(janne): `""`
 - channels(root): `"nixos-18.03"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

This is an old issue, but I ran into the same thing. The problem is that linuxPackages is computed as a fixed point, which has the ability to "undo" any overrides via the __unfix__ attribute, and this is happening somewhere in the config. E.g.,
$ nix repl '<nixpkgs>'
Welcome to Nix version 2.3.9. Type :? for help.

Loading '<nixpkgs>'...
Added 12435 variables.

nix-repl> (linuxPackages // { foo = 1; }).foo
1

nix-repl> (lib.fix (linuxPackages // { foo = 1; }).__unfix__).foo
error: attribute 'foo' missing, at (string):1:1

The correct way to override is to use extend:
nix-repl> (linuxPackages.extend (self: super: { foo = 1; })).foo
1

nix-repl> (lib.fix (linuxPackages.extend (self: super: { foo = 1; })).__unfix__).foo
1

I added a section in the wiki to document this.


Need characters to come across unescaped

Hi!
I've run into an issue with generating a full path to the icons that contains a string like <?php echo ... ?>. Those <> should come across unescaped, but the path written to favicons.php is coming out as <?php echo ... ?</.
Just to be clear, I'm not expecting it to run the PHP script. It should simply write it exactly as entered into the iconsPath option.
Thanks!
Jen
@germanny

Hey @germanny, this should be solved now as of #42.

Thank you!!


BUG : wrong line deleted on "Alarms" tab

A bug detected in Kibana 4 and Kibana 5 branch :

when I am on "Alarms" tab, if I delete the second alarm line, the wrong line is deleted (for example : the first line is deleted)

@lmangani
Finally, after test on Kibana 4.6.3, I reproduce also the issue.
=> So this issue is not specific to Kibana 5.
=> I update the issue title and description.
=> Can you remove "5.0" tag ?

I tested with very latest sentinl version.

Checking! thanks for the update!

Confirmed indeed, gets more severe as reordering of rows takes place. Sorting out a solution.

I think that deleting by elasticsearch Id is the robust solution.
Fabien

Le 14 déc. 2016 à 20:43, Lorenzo Mangani<EMAIL_ADDRESS>a écrit :
Confirmed indeed, gets more severe as reordering of rows takes place. Sorting out a solution.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

We do delete by index/type/id but the table picks the wrong ID due to reordering by timestamp (it seems) I am testing a fix currently.

Nice news !
Fabien

Le 14 déc. 2016 à 20:59, Lorenzo Mangani<EMAIL_ADDRESS>a écrit :
We do delete by index/type/id but the table picks the wrong ID due to reordering by timestamp (it seems) I am testing a fix currently.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Once you'll publish a fix, I'm ready to test it and give feedback.
Fabien

Le 14 déc. 2016 à 20:59, Lorenzo Mangani<EMAIL_ADDRESS>a écrit :
We do delete by index/type/id but the table picks the wrong ID due to reordering by timestamp (it seems) I am testing a fix currently.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I presume you use angularjs ?
This would be clean to have elasticsearch id included in json associated to each table line.
And generate delete link using angularjs and using directly elasticsearch id in current json doc.
Fabien

Le 14 déc. 2016 à 20:59, Lorenzo Mangani<EMAIL_ADDRESS>a écrit :
We do delete by index/type/id but the table picks the wrong ID due to reordering by timestamp (it seems) I am testing a fix currently.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

its all angular, and the right value is already there - resolution is quite trivial in essence, just need time to fit this between other 100 tasks :)

If you reload the alarms page (click about, then back to alarms) is the correct "ghost" alarm you deleted actually gone?

I already tried it this afternoon, several times. And it is still the wrong one that is deleted :(
Fabien

Le 14 déc. 2016 à 22:23, Lorenzo Mangani<EMAIL_ADDRESS>a écrit :
If you reload the alarms page (click about, then back to alarms) is the correct "ghost" alarm you deleted actually gone?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

ok thanks for confirming this, the solution is just a couple lines i will port it here

I understand you have lots of issues to process.
However, you have only two issues that are tagged "bug" and not "5.0".
It sounds like an objective criteria to prioritize this issue :)

I'm sorry? If your guess is this is my only project/task and you'd be terribly wrong :)

I'm really sorry if I tell something that hurt you.
As an opensource commiter on my home time on several projects, I clearly understand it's complicated to answer all issues and you do your best about that. No problem.

The full fix addresses more elements, but as a hotpatch you can try change line 133 in public/templates/alarms.html as follows:

Thanks a lot !
I will try it tomorrow and give you feedback !

I'm sorry to ask that, but what are kibana bundles and where are they ?

I will release a new version with the fix tomorrow morning so hopefully no problem but in general, when you make a change to a plugin file in order for this to take effect you need to manually remove /opt/kibana/optimize/bundles to force Kibana to rebuild them on restart (it takes a while)

Thanks a lot for the release and the tips !
Please put a comment here when you'll release.

Please ignore the manual patch and i'll post here as soon as the new release is out

Fix is available and tested, will be published during the day today - thanks for your patience ;)

Nice news !
Thanks !
Fabien

Le 16 déc. 2016 à 10:24, Lorenzo Mangani<EMAIL_ADDRESS>a écrit :
Fix is available and tested, will be published during the day today - thanks for your patience ;)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi,
Is the release published ?
I presume that every night, a new sentinl-latest.tar.gz is published here
https://github.com/sirensolutions/sentinl/releases/tag/snapshot
Right ?
If so, can you tell me, for info, at what time ?

The build is only triggered when changes are pushed. As this update includes also new features for reports and a few more things, ẃe still need some testing but you are most welcome to join us doing so:
sentinl-latest.tar.gz

Hi @lmangani
I have tested with Kibana 4.6.3, and now, when I delete a line, I got a fatal error :(
 Fatal Error
Error: [$rootScope:inprog] $apply already in progress
http://errors.angularjs.org/1.4.7/$rootScope/inprog?p0=%24apply (http://localhost:4001/bundles/commons.bundle.js?v=10154:27774)

Version: 4.6.3
Build: 10154

Error: Error: [$rootScope:inprog] $apply already in progress
http://errors.angularjs.org/1.4.7/$rootScope/inprog?p0=%24apply (http://localhost:4001/bundles/commons.bundle.js?v=10154:27774)
__WEBPACK_AMD_DEFINE_RESULT__</window.onerror@http://localhost:4001/bundles/commons.bundle.js?v=10154:64667:25
[2297]/</$scope.deleteAlarm@http://localhost:4001/bundles/sentinl.bundle.js?v=10154:113478:10
anonymous/fn@http://localhost:4001/bundles/commons.bundle.js?v=10154 line 41028 > Function:2:798
ngEventHandler/</callback@http://localhost:4001/bundles/commons.bundle.js?v=10154:51255:18
$RootScopeProvider/this.$get</Scope.prototype.$eval@http://localhost:4001/bundles/commons.bundle.js?v=10154:43695:17
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://localhost:4001/bundles/commons.bundle.js?v=10154:43795:21
ngEventHandler/<@http://localhost:4001/bundles/commons.bundle.js?v=10154:51260:18
jQuery.event.dispatch@http://localhost:4001/bundles/commons.bundle.js?v=10154:22814:16
jQuery.event.add/elemData.handle@http://localhost:4001/bundles/commons.bundle.js?v=10154:22501:7

Thanks, this helps! Could you expand the bundle and confirm the line/command causing the error?

Could you try this patched release? sentinl-latest.tar.gz

I just tested your patched release.
And the result is unfortunately the same :(
Fatal Error
Error: [$rootScope:inprog] $apply already in progress
http://errors.angularjs.org/1.4.7/$rootScope/inprog?p0=%24apply (http://localhost:4001/bundles/commons.bundle.js?v=10154:27774)

Version: 4.6.3
Build: 10154

Error: Error: [$rootScope:inprog] $apply already in progress
http://errors.angularjs.org/1.4.7/$rootScope/inprog?p0=%24apply (http://localhost:4001/bundles/commons.bundle.js?v=10154:27774)
__WEBPACK_AMD_DEFINE_RESULT__</window.onerror@http://localhost:4001/bundles/commons.bundle.js?v=10154:64667:25
[2297]/</$scope.deleteAlarm@http://localhost:4001/bundles/sentinl.bundle.js?v=10154:113478:10
anonymous/fn@http://localhost:4001/bundles/commons.bundle.js?v=10154 line 41028 > Function:2:798
ngEventHandler/</callback@http://localhost:4001/bundles/commons.bundle.js?v=10154:51255:18
$RootScopeProvider/this.$get</Scope.prototype.$eval@http://localhost:4001/bundles/commons.bundle.js?v=10154:43695:17
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://localhost:4001/bundles/commons.bundle.js?v=10154:43795:21
ngEventHandler/<@http://localhost:4001/bundles/commons.bundle.js?v=10154:51260:18
jQuery.event.dispatch@http://localhost:4001/bundles/commons.bundle.js?v=10154:22814:16
jQuery.event.add/elemData.handle@http://localhost:4001/bundles/commons.bundle.js?v=10154:22501:7

Sorry for the question, but :
How do I expand the bundle  ?

Thanks @fbaligand I need to really replicate this locally to get to the bottom of it before release.
To expand the bundle you can click the error row and it should indicate where the error spawns.

More info about the context so that you can reproduce the problem :

it happens not everytime.
I invite you to test :

first row
intermediate row
last row

my OS :  windows 10
here the definition of my alarm which generates one console alert per minute :

{
  "_index": "watcher",
  "_type": "watch",
  "_id": "watcher1",
  "_score": 1,
  "_source": {
    "trigger": {
      "schedule": {
        "later": "every 1 minute"
      }
    },
    "input": {
      "search": {
        "request": {
          "index": "logstash*",
          "body": {
            "query": {
              "filtered": {
                "query": {
                  "query_string": {
                    "analyze_wildcard": true,
                    "query": "_type:request"
                  }
                }
              }
            },
            "size": 3
          }
        }
      }
    },
    "condition": {
      "script": {
        "script": "payload.hits.total > 0"
      }
    },
    "transform": {},
    "actions": {
      "to_console": {
        "throttle_period": "1m",
        "console": {
          "priority": "WARN",
          "message": "Series Alarm {{ payload._id}} > 0: {{ payload.hits.total }}"
        }
      }
    }
  }
}

long overdue... latest nightly snapshot has been uploaded with pre-release version (as well as relative branch), including this fix alongside other improvements to guarantee results consistency on add/delete.
NOTE: watcher_alarm-* index mapping changed to support reports

Nice news !
I will test it soon and give you feedback !

Thanks @fbaligand and happy holidays!

@lmangani
Merry Christmas and happy new year ! :)

Hi @lmangani
I tried sentinl last version... and I'm sad to say it's not working at all :(
Here are the details about my test :

I removed sentinl plugin and all its related indexes in elasticsearch
I installed sentinl in Kibana 4.6.3 (on windows 10), using :
kibana plugin -i sentinl -u https://github.com/sirensolutions/sentinl/releases/download/snapshot/sentinl-latest.tar.gz
then, at kibana start, I detect a surprising log error (that I hadn't before, and after sentinl plugin removal, I don't get any more) :
log   [18:57:53.464]<EMAIL_ADDRESS>Status changed from green to red - Unknown config key: elasticsearch.plugins
then, when launching sentinl app, I get a blank screen...
I can see Sentinl header black line, but below, it's blank.
when looking at XHR requests, I saw the following error :
http://localhost:4001/api/sentinl/example raises a 404 Not Found error.

Fixed + new snapshot uploaded.
NOTE: this was due to a Kibi-only lookup we inadvertently left in place, thanks for catching it!

Hi @lmangani
Thanks for the fix.
Now kibana startup works well without error log, and I have no more blank screen when going to sentinl app.
However, I have a new blocking error :

I created a new watcher "watcher1" (the same I mention above in the comments)
and when sentinl executes it, it raises a kibana fatal error : I mean that Kibana is then stopped.
here are the logs :

  log   [18:20:06.436] [info][status][Sentinl] Saving Watcher with ID: watcher1
  log   [18:20:25.145] [info][status][Sentinl] Scheduled Watch: watcher1 every every 1 minute
  log   [18:21:00.006] [info][status][Sentinl] Executing watch: watcher1
C:\Developpement\outils\elk\kibana-4.6.3-windows-x86\installedPlugins\sentinl\server\lib\scheduler.js:146
            if (sirenJoinAvailable) {
                ^

ReferenceError: sirenJoinAvailable is not defined
    at watching (C:/Developpement/outils/elk/kibana-4.6.3-windows-x86/installedPlugins/sentinl/server/lib/scheduler.js:129:17)
    at C:/Developpement/outils/elk/kibana-4.6.3-windows-x86/installedPlugins/sentinl/server/lib/scheduler.js:106:15
    at [object Object].scheduleTimeout [as _onTimeout] (C:\Developpement\outils\elk\kibana-4.6.3-windows-x86\installedPlugins\sentinl\node_modules\later\later.js:846:9)
    at Timer.listOnTimeout (timers.js:92:15)

@fbaligand apologies for this mess and thanks for your useful feedback here - certain SENTINL features require functions stock Kibana does not provide causing this glitch depending on the ES plugin setup. Its finally sorted with the last code and passing tests at least here....

Do you mean you pushished the fix in "Nightly Build 4.x" ?
2016-12-27 10:53 GMT+01:00 Lorenzo Mangani<EMAIL_ADDRESS>
@fbaligand https://github.com/fbaligand apologies for this mess and
thanks for your useful feedback here - certain SENTINL features require
functions stock Kibana does not provide causing this glitch depending on
the ES plugin setup. Its finally sorted with the last code and passing
tests at least here....
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sirensolutions/sentinl/issues/73#issuecomment-269303453,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADk5nKTnXMeaG1IT2CvGhYkPCEvzm77dks5rMOArgaJpZM4LB5no
.

Yes release has been updated, or you can rebuild it locally with:
npm instlal --production
npm run archive

Hi @lmangani
I just tried the last version, and it works great !

no more error at startup
alarms deletion is perfect :

the right line is deleted (whatever its position)
no error is thrown
alarms list is then refreshed

hooray :1st_place_medal: !

@fbaligand thank you so much for testing this during the holidays and for taking time to update status. Your help is much appreciated - next we'll try port those fixes to the 5.x branch and take it from there :)

For 5.x branch, should I open a new issue ?

@lmangani
Do you have ported fix on 5.x branch ?
Do you want that I open a new issue for 5.x branch ?

@lmangani
Do you have ported fix on 5.x branch ?
Do you want that I open a new issue for 5.x branch ?

Yes please, we need to track this separately for 5.x

OK !
That's done : #88


SC4S: Add official support for AWS Fargate

Customer has standardized on AWS Fargate and is requesting official support for SC4S with AWS Fargate.

@splunkin,
Could you please elaborate more on this issue?
And please send relevant link references which helps us to add official support.

We dont support it now , we will update the community as soon as we will have the plan for it.
Closing it as duplicate request.


Launch Webviews as incognito

Is your feature request related to a problem? Please describe.
For browser based OAuth where you cannot guarantee the existence of a web browser but can guarantee the existence of a WebView, having an option to launch a webview as incognito would be useful.
Would you want to assign yourself to implement this feature?

[ ] Yes
[ ] No

Other (I did a PoC for WebView2)
Additional context
On Windows, it could be done by modifying InnerWebView::create_controller to something like this:
  fn create_controller(
    hwnd: HWND,
    env: &ICoreWebView2Environment,
    incognito: bool
  ) -> webview2_com::Result<ICoreWebView2Controller> {
    let (tx, rx) = mpsc::channel();
    let env = env.clone().cast::<ICoreWebView2Environment10>()?;
    let controller_opts = unsafe {env.CreateCoreWebView2ControllerOptions()?};

    unsafe {controller_opts.SetIsInPrivateModeEnabled(incognito)?}

    CreateCoreWebView2ControllerCompletedHandler::wait_for_async_operation(
      Box::new(move |handler| unsafe {
        env
          .CreateCoreWebView2ControllerWithOptions(hwnd, &controller_opts, &handler)
          .map_err(webview2_com::Error::WindowsError)
      }),
      Box::new(move |error_code, controller| {
        error_code?;
        tx.send(controller.ok_or_else(|| windows::core::Error::from(E_POINTER)))
          .expect("send over mpsc channel");
        Ok(())
      }),
    )?;

    rx.recv()
      .map_err(|_| webview2_com::Error::SendError)?
      .map_err(webview2_com::Error::WindowsError)
  }

It would be needed to cast env to ICoreWebView2Environment10 first as ICoreWebView2Environment wouldn't have CreateCoreWebView2ControllerWithOptions.

webkit2gtk can enable it via SettingsExt trait.

Any idea for macOS/iOS and Android? I do have both Windows and WebKitGTK both implemented now (but I did have to use is_ephemeral on WebViewBuilder rather than enable_private_browsing to make the behavior more consistent like on Windows)


[BUG] Audio streaming only available if source is 'microphone' on Ubuntu 22.04

Describe the bug
Can't run web UI
To Reproduce
python tools/webui...
Expected behavior
Run
Screenshots / log
python tools/webui.py \
    --llama-checkpoint-path checkpoints/fish-speech-1.2-sft \
    --decoder-checkpoint-path checkpoints/fish-speech-1.2-sft/firefly-gan-vq-fsq-4x1024-42hz-generator.pth

/usr/lib/python3/dist-packages/scipy/__init__.py:146: UserWarning: A NumPy version >=1.17.3 and <1.25.0 is required for this version of SciPy (detected version 1.26.4
  warnings.warn(f"A NumPy version >={np_minversion} and <{np_maxversion}"
2024-07-19 18:59:57.695 | INFO     | __main__:<module>:523 - Loading Llama model...
2024-07-19 19:00:03.030 | INFO     | tools.llama.generate:load_model:347 - Restored model from checkpoint
2024-07-19 19:00:03.030 | INFO     | tools.llama.generate:load_model:351 - Using DualARTransformer
2024-07-19 19:00:03.031 | INFO     | __main__:<module>:530 - Llama model loaded, loading VQ-GAN model...
2024-07-19 19:00:04.087 | INFO     | tools.vqgan.inference:load_model:44 - Loaded model: <All keys matched successfully>
2024-07-19 19:00:04.087 | INFO     | __main__:<module>:538 - Decoder model loaded, warming up...
2024-07-19 19:00:04.088 | INFO     | tools.api:encode_reference:117 - No reference audio provided
2024-07-19 19:00:04.120 | INFO     | tools.llama.generate:generate_long:432 - Encoded text: Hello, world!
2024-07-19 19:00:04.120 | INFO     | tools.llama.generate:generate_long:450 - Generating sentence 1/1 of sample 1/1
  0%|                                                                         | 0/4080 [00:00<?, ?it/s]/home/pm/.local/lib/python3.10/site-packages/torch/backends/cuda/__init__.py:342: FutureWarning: torch.backends.cuda.sdp_kernel() is deprecated. In the future, this context manager will be removed. Please see, torch.nn.attention.sdpa_kernel() for the new context manager, with updated signature.
  warnings.warn(
  1%|▌                                                               | 39/4080 [00:01<02:46, 24.21it/s]
2024-07-19 19:00:06.246 | INFO     | tools.llama.generate:generate_long:505 - Generated 41 tokens in 2.13 seconds, 19.28 tokens/sec
2024-07-19 19:00:06.247 | INFO     | tools.llama.generate:generate_long:508 - Bandwidth achieved: 9.45 GB/s
2024-07-19 19:00:06.247 | INFO     | tools.llama.generate:generate_long:513 - GPU Memory used: 1.42 GB
2024-07-19 19:00:06.266 | INFO     | tools.api:decode_vq_tokens:128 - VQ features: torch.Size([4, 40])
/home/pm/.local/lib/python3.10/site-packages/torch/nn/modules/conv.py:306: UserWarning: Plan failed with a cudnnException: CUDNN_BACKEND_EXECUTION_PLAN_DESCRIPTOR: cudnnFinalize Descriptor Failed cudnn_status: CUDNN_STATUS_NOT_SUPPORTED (Triggered internally at ../aten/src/ATen/native/cudnn/Conv_v8.cpp:919.)
  return F.conv1d(input, weight, bias, self.stride,
2024-07-19 19:00:07.330 | INFO     | __main__:<module>:555 - Warming up done, launching the web UI...
/mnt/phil/fish-speech-main/tools/webui.py:343: UserWarning: You have unused kwarg parameters in Checkbox, please remove them: {'scale': 0, 'min_width': 150}
  if_refine_text = gr.Checkbox(
Traceback (most recent call last):
  File "/mnt/phil/fish-speech-main/tools/webui.py", line 557, in <module>
    app = build_app()
  File "/mnt/phil/fish-speech-main/tools/webui.py", line 439, in build_app
    stream_audio = gr.Audio(
  File "/home/pm/.local/lib/python3.10/site-packages/gradio/components.py", line 2387, in __init__
    raise ValueError(
ValueError: Audio streaming only available if source is 'microphone'.

Additional context
RTX 3060 (12GB)
Driver Version: 550.67         CUDA Version: 12.4

Maybe you need to install a brand new python=3.10 environment, then pip install -e .

Maybe you need to install a brand new python=3.10 environment, then pip install -e .

Maybe I need to install a brand new python=3.10 environment, then pip install -e . :smile:


Add smooth-hv support.

Also updates to Dec 14, and fixes build on gcc 7.

This passes my local desync test. (BasketballDrive_1920x1080_50_1s.y4m)


test(api): Replace pytest-aiohttp with pytest-asyncio for running async tests

Overview
Our test framework, pytest, does not natively support async test functions or fixtures. Various 3rd-party plugins take up that responsibility. For historical reasons, the plugin that we've been using is pytest-aiohttp, which isn't a good fit for us because we're not even using the aiohttp web server in this project.
This PR replaces pytest-aiohttp with pytest-asyncio, a much smaller plugin from the pytest devs that's specifically meant for running async tests.
Benefits to this include:

No longer needing confusing loop boilerplate arguments for async fixtures.
Replacing a big dev dependency with a much smaller one. (pytest-aiohttp pulled in the whole aiohttp web server library.)
Speeding up the test suite from 4m50s to 1m30s, on my machine.

This addresses half of #8176, with the other half being robot-server. See https://github.com/Opentrons/opentrons/issues/8176#issuecomment-1100568533 for why I went with pytest-asyncio instead of anyio.
Changelog

Remove the pytest-aiohttp dev dependency and replace it with pytest-asyncio.
pytest-aiohttp's magic loop fixture now no longer exists. If a fixture or test function was requesting it, remove it. If it was actually using it, replace that usage with asyncio.get_running_loop().
Some def things secretly needed to be running in an event loop, even though they never await anything. Make them async def to help pytest-asyncio pick them up.
Remove the asyncio_loop_exception_handler fixture, which I couldn't port.

Review requests

Skim the diff and make sure nothing snuck in. The easiest way to scan through the changes might be commit-by-commit.
Pull this branch, run make -C api teardown && make -C api setup, and then run some pytest commands. Make sure they keep reporting what they were reporting before. In particular, make sure results don't change between running the whole suite and running individual files or functions.

Risk assessment
I think low. Async stuff in pytest is inherently a huge mess, so there's some risk because of that, but, I mean...can this be any worse than pytest-aiohttp?

 I had no idea this plugin was causing such harm to our test suite.

Yeah, this was a happy surprise for me, too. :)

There's a few places where we could use the event_loop fixture instead of asyncio.get_running_loop(). I think I'm more in favor of the latter (as this PR is written) but I'm unaware of the implications one way or another. There are enough open issues about event_loop in the pytest-asyncio repo to make me nervous about using it.

I totally missed that that fixture even existed. Thanks for the pointer. I also don’t have an informed opinion on whether we should be using it or get_running_loop(). In the absence of a reason to prefer the fixture, I’ll keep us using get_running_loop() for now, since it’s a bit less magical.

Reading through this PR, I also think at some point we should re-evaluate all these explicit loop parameters spread across our codebase and remove most, if not all, of them

:100:


Update for MP6

Add Telemetry
update for MP6

@Emily-Jiang
I find the error  @Health is deprecated.  so I should replace it by @Liveness ,@Readiness.

@Emily-Jiang I find the error @health is deprecated. so I should replace it by @Liveness ,@readiness.

Depending on which version of MP health you are talking about. It was only deprecated later. It was fine in the earlier version of MP Health. I suggest you to fix the test error first not to change other things.

@luiseufrasio did you figure out what was the test failures and propose a update on the PR to unblock this?

clipsefdn/eca

@Emily-Jiang the tests seems to be NOT running: https://github.com/eclipse/microprofile-starter/pull/494/checks
I says "Workflow runs completed with no jobs"

The conflict needs to be solved before the tests can be executed. @majidmostafavi can you please resolve the conflicts and then the CI jobs can be launched?

Why is there a v7 of the Api created when it is identical to v6?

Why is there a v7 of the Api created when it is identical to v6?

v7 has Telemetry added though.

The version of the API has nothing to do with the config op the MP versions and the options.  It is about the available endpoints, their parameters and responses.
So /api/mpVersion/MP60, /api/7/mpVersion/MP60, and , /api/6/mpVersion/MP60 all return
{"specs":["CONFIG","FAULT_TOLERANCE","JWT_AUTH","METRICS","HEALTH_CHECKS","OPEN_API","REST_CLIENT","TELEMETRY","GRAPHQL"],"supportedServers":["LIBERTY"]}

Even the API versions 2 and higher, all return this result which includes Telemetry.
So there is no need at all to have a new API version.

The version of the API has nothing to do with the config op the MP versions and the options. It is about the available endpoints, their parameters and responses.
So /api/mpVersion/MP60, /api/7/mpVersion/MP60, and , /api/6/mpVersion/MP60 all return
{"specs":["CONFIG","FAULT_TOLERANCE","JWT_AUTH","METRICS","HEALTH_CHECKS","OPEN_API","REST_CLIENT","TELEMETRY","GRAPHQL"],"supportedServers":["LIBERTY"]}

Even the API versions 2 and higher, all return this result which includes Telemetry.
So there is no need at all to have a new API version.

I thought the earlier version of MP (1.x-5.x) should NOT return Telemetry @rdebusscher

Earlier versions of MP will not return Telemetry. As I already said, MP Version and API version of the Starter app are 2 independent things.

Earlier versions of MP will not return Telemetry. As I already said, MP Version and API version of the Starter app are 2 independent things.

Should the earlier API version such as 2.x return Telemetry at all?

Earlier versions of MP will not return Telemetry. As I already said, MP Version and API version of the Starter app are 2 independent things.

Should the earlier API version such as 2.x return Telemetry at all?

In my opinion, yes. Those that make an integration with the API should not use latest version since that can have breaking changes at any time. Only a certain API version is stable.
And having all options in all API versions doesn't force external parties to update their integration with the MP Starter API.

Earlier versions of MP will not return Telemetry. As I already said, MP Version and API version of the Starter app are 2 independent things.

Should the earlier API version such as 2.x return Telemetry at all?

In my opinion, yes. Those that make an integration with the API should not use latest version since that can have breaking changes at any time. Only a certain API version is stable. And having all options in all API versions doesn't force external parties to update their integration with the MP Starter API.

Thanks @rdebusscher ! @majidmostafavi you don't need to create a new version of the API.

@Emily-Jiang  I found the way to fix the issues from the  API MicroProfile Starter but I cant add commits on this PR, it seems someone needs to give me some permission:
remote: Permission to majidmostafavi/microprofile-starter.git denied to breakponchito. fatal: unable to access 'https://github.com/majidmostafavi/microprofile-starter.git/': The requested URL returned error: 403 00:12:20.257: [microprofile-starter] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain majid refs/heads/majidMain:main remote: Permission to majidmostafavi/microprofile-starter.git denied to breakponchito. fatal: unable to access 'https://github.com/majidmostafavi/microprofile-starter.git/': The requested URL returned error: 403

@Emily-Jiang @cesarhernandezgt I found the way to fix the issues from the API MicroProfile Starter but I can't add commits on this PR, it seems someone needs to give me some permission:
remote: Permission to majidmostafavi/microprofile-starter.git denied to breakponchito. fatal: unable to access 'https://github.com/majidmostafavi/microprofile-starter.git/': The requested URL returned error: 403 00:12:20.257: [microprofile-starter] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain majid refs/heads/majidMain:main remote: Permission to majidmostafavi/microprofile-starter.git denied to breakponchito. fatal: unable to access 'https://github.com/majidmostafavi/microprofile-starter.git/': The requested URL returned error: 403 probably I should need to recreate the PR

@breakponchito it was the branch from @majidmostafavi . I think you can checkout his branch and then do a new PR.

@Emily-Jiang @cesarhernandezgt I found the way to fix the issues from the API MicroProfile Starter but I can't add commits on this PR, it seems someone needs to give me some permission:
remote: Permission to majidmostafavi/microprofile-starter.git denied to breakponchito. fatal: unable to access 'https://github.com/majidmostafavi/microprofile-starter.git/': The requested URL returned error: 403 00:12:20.257: [microprofile-starter] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain majid refs/heads/majidMain:main remote: Permission to majidmostafavi/microprofile-starter.git denied to breakponchito. fatal: unable to access 'https://github.com/majidmostafavi/microprofile-starter.git/': The requested URL returned error: 403 probably I should need to recreate the PR

@breakponchito it was the branch from @majidmostafavi . I think you can checkout his branch and then do a new PR.
git checkout -b majidmostafavi-main main
git pull https://github.com/majidmostafavi/microprofile-starter.git main

yes I already create a new PR here: https://github.com/eclipse/microprofile-starter/pull/499
it seems that I need an approval from a maintainer
@Emily-Jiang Could you help me with this?


Clearify request, question and answer

Can you clarify in the Information if this integration can be used without internet? In other words: if it has local control in a good DHCP network, but without internet. Maybe internet only for setup? I'm asking because I have no internet in a rural area and want to buy this Garenda system.
Answer on your question
"TODO
Do we need support for more than one location? Should we make it
possible to configure it?"
I don't know that answer! But for the !Privacy First! and remote networks without internet in rural area. Make shure it works without internet if that's isn't the case please! ;-)

Hello MrUserY,
Unfortunately, the component won't work without internet.
The Gardena component relies on an internet service provided by Gardena and we have no way to avoid this communication. Please contact gardena, so they can add an API directly in the smart gateway :)
Regards,
Grm


[Update] Extending supported networks for Sygnum Web3 Recovery

Entry type

Update

App info

no update

Supported networks

- Mainnet (existing)
- Optimism (existing)
- Arbitrum
- Base
- Polygon
- Gnosis Chain
- Binance SC

Revision checks

no update

Audit document

no update

Code for review

no update

Team information

no update

Verified

All chains are enabled now.


X-Forwarded-For / X-Envoy-External-Address Headers not propagated correctly

Description

During investigation of https://github.com/kyma-incubator/reconciler/issues/959 we noticed that our Audit Logs stopped working correctly due to us not being able to read out X-Forwarded-For headers anymore. This is apparently a regression as we previously used X-Envoy-External-Address to fetch our IP. I aligned with @veichtj and it seems that we currently do not have support for this from the Istio managed by Kyma. Nevertheless, Apps in the Control Plane will need access to any form of X-Forwarded-For to support correct Audit Logging

Expected result
I expect Audit Logs to be writable from any Pod within the control-plane mesh to have access to X-Forwarded-For style headers to write proper Audit Logs

Actual result
No XFF Headers are set and can be read from Applications running inside control-plane

Steps to reproduce
A detailed deployment for reproduction is available in the linked issue. You will need to have access to an audit log instance or an application that is able to read out XFF headers. This can be replicated, e.g. by sending requests via KCP CLI or any other external application calling the control-plane

Troubleshooting
I have discussed with the Istio team on the solution and debugged the issue to verify that the IP headers are missing. The missing IP causes Bad Request (400) responses on the SAP Audit Log Service, so it is easy to spot for us.

Related to #13492

@strekm : any news regarding this Istio limitation: Is it maybe gone with the newer versions?

@tobiscr @jakobmoellersap we have it on our radar

closing as duplicate of https://github.com/kyma-project/kyma/issues/13730