CMake: Dont postfix debug builds on unix

No description? Then a few questions. If I first build a debug version, and later a release one. What happens?

It replaces the files at install time? Not sure I understand the question

Corrcet. The debug-enabled lib is replaced with a non-debug version, but the config.cmake files stay as they are. So everyone that uses cmake will be get the debug-flags for compile and then get linker errors, because of the debug-lib doesn't have the functions included.
Your change would be right for libs that don't have different features compiled in, here it just causes troubles.
And I asked for a description to get idea why you think it's good to things that are in there by purpose.

Hi @Vollstrecker, firstly thanks for the CMake work, its amazing.
I made this change to bring it into line with behaviour of the existing autotools build system, with the hope that it will replace it at some point.
Linux systems usually don't rename the libraries for debug builds, I have never seen it my time on Linux. Instead the symbols simply get included into the libraries. Or if build by a distribution, the symbols are stripped and shipped separately installable.
If applications are relying on upnp internal debug methods, then that would be very odd indeed, why are those symbols even exported? I see this as more of a bug. If so then they should check the upnpconfig.h to ensure that the debug support they need was there, like any other option?
I would imagine that most consumers in the wild are not using CMake, so they just see the libs with the names they expect missing in debug mode.
I may be missing something obvious of course!

Keeping it in line with the autotools sounds good for the first view, but these use pkgconfig, which doesn't differentiate so far. In autotools-scripts it is easy to check if the *d.so there, and then choose what to use.
On windows it's for libs common practice, as they use the lib extension for everything.
The problems with the symbols can be seen in upnpdebug.h, Most of the funcs are inlined when building without debug, and normal when built with. Same for upnpdebug.c, which is just empty in non-debug builds. best would be to remove the ifdef in upnpdebug.c, but that's something @mrjimenez  has to decide.

HI,
I have no hard feelings about the way upnpdebug is done. If anyone believes that the current implementation is somewhat problematic, please state your reasons and send a pull request that it will be rationally appreciated.
The current implementation aims to keep the internal upnp code invariant independent of the build mode (debug or not). So, in principle you are able to stuff debug code inside the library without badly affecting code size and speed in non-debug builds, since the compiler would take care of substituting void code by nothing. As a result, debug ifdefs are not required in the library code, and this is a Good Thing (TM), since those debug ifdefs are mainly visual polution.
I agree that other applications should not be using internal upnp debug routines, if that is the case it is definitely buggy and I am in favor of removing the exportation of this "API", but as always I might be missing something.
Regards,
Marcelo.

I don't get it. If you get libs with different functions from different build-modes, I wouldn't call it invariant.
And jep, in eyes it's a good thing to not carry the debug parts through releases, that's why I prefer how it is done now. And sure, the internal routines should be internal only, but they should be there. Given that a developer doesn't get it working like expected, then a blackbox is always bad, the additional debug output is very welcome.

I don't get it. If you get libs with different functions from different build-modes, I wouldn't call it invariant.

The point of view if the written code. The code is invariant, meaning it is the same code for both builds, even if it generates zero executable instructions. The current scheme leaves the ifdefs out of the library code and leave them in the headers, making it more pleasant to read.
As for this patch, I tend to agree with @whyman that in Linux in general packagers don't rename their libraries with a debug version. There are packages with debug symbols that must be installed if you want them to debug or generate readable backtraces. That way the libraries are not recompiled. I don't remember having to link to a library with a different name to debug any application.
In my opinion, the functions in upnpdebug should compile to null code in the real world, even in a postfixed debug enabled library. These functions are supposed to be for the developer's eyes only since they create serious performance and timing issues. The confusion arises from the fact that --enable-debug, which enables debug symbols, also enables this functionality and maybe that is the root of the problem. Should there be separate --enable-debug-symbols / --enable-debug options?

| The point of view is of the written code
k, from the one code for all point of view you're right.
| As for this patch, I tend to agree with @whyman that in Linux in general packagers don't rename their libraries with a debug
| version
Right, too. The usually decide for debug-version strip the symbols to a separate file and good. This is even possible now, even with the release version.
| There are packages with debug symbols that must be installed if you want them to debug or generate readable backtraces
Again right. As the symbols are used for gdb or alike. But all functions are in the lib, and that's the difference to here. If you add DEBUG and UPNP_HAVE_DEBUG as compile-flags to one of the tests, compilation in Release-Mode fails, as the expect the functions from debug (not inlined) in the lib, where they are not found.
It's like when you ship the pkgconfig file with the flags for both, but only ship the release one.
| In my opinion, the functions in upnpdebug should compile to null code in the real world, even in a postfixed debug enabled
| library.
You mean even when debug is requested? Then the easiest way would be to put the inlined functions into a separate header, and force the endusers to include the header with the non-inline version by their own if they really need it. And maybe putting a Warning for packagers to not use debug-build for packaging. But even in this case I would highly recommend to keep the naming difference as it was, as it makes it easier for dev to use the lib if they know what they are doing, without affecting the whole system. If noone uses the debug build, noone will notice the second lib.

Addendum: For sure you never noticed using different lib to link. With autotools you don't create them. wx for example does it when built with cmake, and cmake does the magic to give the right lib to your code.
So no cmake = one lib, no change, no problem
cmake = two libs but you'll never notice, no problem

Addendum 2: If built with cmake and the prog that's is using it uses autotools, it will either search for the lib with no postfix, so no change, or it will use pkgconfig which point it to the non-postfixed release version with the release flags.
So the only difference are some extra bytes on disk for the second lib.


update packages

:white_check_mark: Build TheIdServer 3.0.1-fix-dependencies1-0057 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/3f0d8c9879 by @)


IE11 errors due to incomplete transpiling

Parts of the vue-text-highlight.min.js are not being transpiled, leading to errors in IE11. The function createInjector for example contains an arrow function (=>) which throws an error in IE11.

@MariusRumpf thanks for raising this issue. This should be fixed in v2.0.6.


distinguish predicates and properties

as @sstucki pointed out, there are predicates having the names of properties. this is ultimately due to the old library. on the other hand, we want to keep the style of this library as close to stdlib as possible, so it does make sense to define X and IsX separately.

I'm not always fond of the IsX stuff. It would be especially odd in CT, where 'flat' theories seem to make sense. Having said that, I'm sure there are cases where the current setup is wrong, and should be fixed.

what do you mean? I suppose this is more like a stylistic issue, isn't it?

I don't like the IsMonoid structure that separates out all the properties into a bundle, with the rest 'unbundled'. It's a holdover from a combination of over-focusing on computation and downplaying proofs, and proof-irrelevance, which while not downplaying proofs as much, still says that there is no actual information content to proofs.  This library is proof-relevant...
It is definitely a stylistic issue.

It is definitely a stylistic issue.

I guess that's true, but the reason why I mentioned this in #40 wasn't really stylistic. It was actually rather pragmatic. I was trying to implement the category Groupoidsof groupoids and functors, so I needed a structure Groupoid (of type Set o) for the objects. There was already a record Groupoid (in Categories.Category.Groupoid) but that wasn't the structure, it was a predicate on categories, the property of being a groupoid. Of course, I could have used Σ (Category _ _ _) Groupoid as the type of objects, but that's not very readable. I prefer to use records to give proper names to structures.
So my question is really: when there's a structure Ythat is an X with extra properties, and there are good reasons to both represent the structure Yand the property (predicate on Xs) of being a Y, how should the two be distinguished?
Note that I'm in no way suggesting that the predicate is somehow less important or that it has no information content. It simply has a different type, which I think should be reflected somehow in the name.

at this moment it is really done by repeating X. see for example:
https://github.com/agda/agda-categories/blob/e84322e61f4e43f6efea7cc049beeb0e987cd3b8/Categories/Functor/Monoidal.agda#L20-L27
indeed, if Monoidal were a structure instead of a predicate, this definition would look a bit more natural.

So I agree that, right now, Groupoid is ill-named, because it isn't the structure/type, but a predicate. I would be happy to change its name, and introduce a proper Groupoid.
Monoidal is to me different, because it adds additional structure on top of underlying structure. And you not infrequently want 2 monoidal structures on the same underlying category.
I guess I'd prefer to start with fixing the obvious cases that are wrong, and see what kind of naming convention emerges. I'm happy to release 0.X versions that are actively advertised as having a slightly unstable API -- and then ensure the 1.0 version stabilizes the core API. I don't feel like I quite know enough right now to suggest a naming convention that's going to be sufficiently future-proof.

The Groupoid issue has now been taken care of.
In most presentations of monoidal categories, it starts with "A Monoidal category is a category equipped with ...". So it does feel like it is naturally an over-structure; it definitely isn't a 'predicate'.
Interestingly, the one that I'm still most unsure of is Apex as part of Cone!  In some of the uses, it would be better parametrized, and others like it is, as a structure. So I am quite undecided. [Or maybe it's the other way around, it's Cone that should be parametrized]

So things have definitely 'evolved' since this issue was created. We do have a bunch of IsX and also X. It does seem to work just fine.
The question is now: what's left to do to close this particular issue? There doesn't seem to be any active, outstanding items?

So things have definitely 'evolved' since this issue was created. We do have a bunch of IsX and also X. It does seem to work just fine.
The question is now: what's left to do to close this particular issue? There doesn't seem to be any active, outstanding items?

It's been a month since I asked about this, and no comments. Re-reading makes me think there's nothing left to do. At least, this issue won't caused any more direct work.


VS Code language service is broken in 1.1.0 due to unessecary package

Bug Report or Feature Request (mark with an x)
- [x] bug report

Versions.
cli 1.1.0
VS Code Angular Language Service 0.1.3
Repro steps.

Use VS Code with official Angular Language Service plugin installed.
Create a project with CLI.
Completion and error checking in HTML external templates doesn't work.
npm uninstall @angular/language-service
Restart VS Code.
Now it works.

Desired functionality.
VS Code Angular Language Service plugin seems to use :

it's own install of @angular/language-service if it's not present in node_modules
if present, it uses the project dependency, and unfortunately, the plugin is not always up to date with the last release of @angular/language-service.

I see no use to pre-install @angular/language-service as the developer won't use it directly, and plugins should manage their own dependencies to be sure to use the good version.
So I think commit bb99fac should be reverted.
I've open the same issue in VS Code Angular Language Service project too : angular/vscode-ng-language-service#102

Note : adding the @angular/language-service by default will be great when we'll be able to just add in tsconfig.json :
"plugins": [{ "name": "@angular/language-service" }]
Then Angular language service will be working out of the box, with no plugin needed.
But it's not ready yet, as it only works with inline templates for now (external templates support is waiting for a new TypeScript feature).

@sumitarora can you take a look?

@filipesilva I can confirm it's not working as expected for external templates. We can wait for the plugin to fix the issue as it seems to be an issue with VS code only.

这个玩意儿，不能用好久了，我看了很多的讨论，都没什么结果，总之就是一句话，等！！！！！我靠

Closing, as it seems to be OK with last versions (even if the issue in angular/vscode-ng-language-service#102 wasn't closed).


Sys: Use GitHub releases as kernel source

Closes https://github.com/hermitcore/rusty-hermit/issues/193.
Note that this results in using a hardcoded kernel version instead of using the latest one. This is similar to us explicitly updating the submodule instead of using the latest git version. While we could use the latest version, I am not sure if it makes sense. What do you think? :thinking:

I'll try finding a more lightweight http client than reqwest. 🤔

bors r+


[Change Title]
[Brief description of the change]
[Describe the outdated practice and what would be preferred for modern code]

Issue metadata

Issue type: sample-update

#5672


allow out-of-tree platforms to be dynamically added

Current Behavior
External platforms, such as Windows, cannot use haul without forking it. This is due the platforms array ['android','ios'] being hardcoded in makeReactNativeConfig.
Expected Behavior
Out-of-tree platforms like Windows, Linux, and MacOS, should be able to use haul without forking haul.
In our initial rn-cli.config PR, we were told the new configuration would allow for out-of-tree platforms, but it turned out not to.
cc @grabbou ,we talked about this back in December and you had a clear idea on how to enable this.

This could be closed, am I right, @acoates-ms? 💪


ffprobe: added EOF to the list of ignored errors

As reported in https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/issues/601, there sometimes is an EOF error on ffprobe process close which prevent from retrieving the metadata even though they have been successfully extracted.

Do you know when will these changes be published to npm ?


Integrate Yii2-powered SO-like forum

https://github.com/ShNURoK42/linuxforum
It seems, that it is in Russion, but since it is in Yii2, then translation and integration into any other Yii2 application shouldn't be a much problem.

Closed and migrate as a part of  yiinsanedevs/yii2-support-app project.


Could you release 256*256 model?

Hi, It is a great work. And I wonder if you can release the model with the size of 256256 other than 512512?

I am kind of busy right now. For now, you can use resize the input image to 512 and use the 512 model.


Added method to clear all inboxes in WriteNotification class.

Codecov Report

Merging #167 into master will increase coverage by 0.11%.
The diff coverage is 55.55%.

@@             Coverage Diff              @@
##             master     #167      +/-   ##
============================================
+ Coverage      64.3%   64.42%   +0.11%
- Complexity      423      424       +1
============================================
  Files            61       61
  Lines          1779     1785       +6
  Branches        186      187       +1
============================================
+ Hits           1144     1150       +6
  Misses          579      579
  Partials         56       56

Impacted Files
Coverage Δ
Complexity Δ

...rc/seedu/addressbook/commands/DispatchCommand.java
55.55% <100%> (ø)
3 <0> (ø)
:arrow_down:

src/seedu/addressbook/inbox/WriteNotification.java
83.33% <42.85%> (+1.85%)
7 <2> (+1)
:arrow_up:

Continue to review full report at Codecov.

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


React: use forwardRef within ReactAsset to allow for passing of ref through "props".

Is your feature request related to a problem? Please describe.
I'm currently attempting to implement React Hook Form to coincide with Player in a React Webapp. React Hook Form utilises a register function that passes props through to a component. An example of this could be:
<input
  id={"my-field"}
  type={"text"}
  {...register("exampleField")}
/>

This register function spreads a few props to the element; name, onBlur, onChange and ref.
Due to the nature of how React Ref works, ReactAsset consumes the Ref. Docs here.
Describe the solution you'd like
I believe implementing the React forwardRef to the ReactAsset component would solve this issue. This is under the assumption that the current system does not have an alternative method to solve this issue. By my understanding, this should not cause issues with components who are not expecting a ref, allowing "backwards compatibility" from this change.
An example solution:
// Callback Type - As specified from ReactHookForm's definition of the `ref` returned by `register`
export type RefCallBack = (instance: any) => void;

export default forwardRef<
  RefCallBack,
  AssetType<string> | AssetWrapper<AssetType<string>>
>(function ReactAsset(
  {
    ...rest
  },
  ref
) {

Thank you!

EDIT: This will be unnecessary in React 19 - source: https://react.dev/blog/2024/04/25/react-19#ref-as-a-prop


Endpoint to remove a registry and reset the list of registries

Is registry list reset endpoint implemented?

I think this is not needed anymore because this PR should replace it AFAIK


labelAttribute function?

Is it possible to format the final search string rather than just using a named attribute?
For example a combination of 2 fields from the resulting object?

You can always create a custom template, which gives you the ability to fully customize the results.
See the README for more info.

Thank you for the quick reply.  Yes, I've noticed the results are fully customizable but the actual search string after selecting a result is what we're trying to customize more than just labelAttribute.  We would like to continue using the entire Object returned when labelAttribute is undefined but also customize the search string query after clicking the result.  For example see the attached image that may help better explain.

I was able to achieve this by doing a .setValue  on the autoCompleteComponent following the itemSelected event.


Text panicked at 'min > max, or either was NaN

Bevy version
0.11
What you did
use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, setup)
        .run();
}

fn setup(mut commands: Commands) {
    commands.spawn(Camera2dBundle::default());
    commands.spawn(NodeBundle {
        style: Style {
            flex_direction: FlexDirection::Column,
            width: Val::Percent(100.),
            ..Default::default() },
        ..Default::default()
    })
    .with_children(|commands| {
        for (text_alignment, justify_content, color) in [
            (TextAlignment::Left, JustifyContent::Start, Color::MAROON),
            (TextAlignment::Center, JustifyContent::Center, Color::DARK_GREEN),
            (TextAlignment::Right, JustifyContent::End, Color::NAVY),
        ] {
            commands.spawn(NodeBundle {
                style: Style {
                    flex_direction: FlexDirection::Row,
                    justify_content,
                    ..Default::default()
                },
                ..Default::default()
            })
            .with_children(|commands| {
                let text_bundle = TextBundle::from_section(
                    format!("JustifyContent: {justify_content:?}\nTextAlignment::{text_alignment:?}"),
                    TextStyle {
                        font_size: 25.,
                        ..Default::default()
                    },
                )
                .with_text_alignment(text_alignment)
                .with_background_color(color);
                commands.spawn(text_bundle);
            });
        }
    });
}

What went wrong
thread 'Compute Task Pool (0)' panicked at 'min > max, or either was NaN. min = 393.75, max = 375.0', /rustc/eb26296b556cef10fb713a38f3d16b9886080f26\library\core\src\num\f32.rs:1430:9

This bug was reported before on discord but without a replication

The key is the missing colon in the first line of the text:
format!("JustifyContent: {justify_content:?}\nTextAlignment::{text_alignment:?}")

Fix it:
format!("JustifyContent: {justify_content:?}\nTextAlignment::{text_alignment:?}")

The example no longer panics:

For some reason, the right-aligned min-content-width is larger, not sure why yet:
min-content-width version should be:
          JustifyContent:
  JustifyContent::End,
TextAlignment::Right,

max-content-width version should be like this:
JustifyContent: JustifyContent::End,
                      TextAlignment::Right,

Got it, with TextAlignment::Right it adds an extra space before the right edge for some reason.


Incorrect Line in Yaml for false positive

My yaml file starts with this content:
---
version: "3.9"

x-common-variables: &common-variables
  POSTGRES_DB: postgres
  POSTGRES_USER: odoo
  POSTGRES_PORT: 5432
  POSTGRES_PASSWORD: odoo

services:
  odoo:

detect-secrets throws:
ERROR: Potential secrets about to be committed to git repo!

Secret Type: Secret Keyword
Location:    src/myproject/docker-compose.yml:11

Saying potential secret is on line 11, but its actually on line 8. I found similar issue here: https://github.com/Yelp/detect-secrets/issues/503
P.S. Using v1.4.0.

For one of my yaml files, scan even gives line numbers that are higher than the total number of lines. When running audit, the secret is be displayed in cleartext, but it then crashes when trying to find and highlight the code snippet with the secret (#634).

Got same behaviour -- line 220 out of 148. I think it's incorrect parser behaviour -- it count lines after references (*here -> &here) substitution.

Hi @oerp-odoo. Thank you for report this. Can you please let me know what commands you are running. I tried to reproduce this on my machine and this is my output.
Is it reproducible if you just use those lines in a new file? Ignoring the remainder of the file? I am trying to gauge if there is a parsing issue later in the file that I cannot see.
Fiile test.yaml:
---
version: "3.9"

x-common-variables: &common-variables
  POSTGRES_DB: postgres
  POSTGRES_USER: odoo
  POSTGRES_PORT: 5432
  POSTGRES_PASSWORD: odoo

services:
  odoo:

Scan: detect-secrets -v scan test.yaml --disable-filter detect_secrets.filters.gibberish.should_exclude_secret
Output:
  "results": {
    "test.yaml": [
      {
        "type": "Secret Keyword",
        "filename": "test.yaml",
        "hashed_secret": "2269658f8a074e5c0fbaffd33897bef741e62d8a",
        "is_verified": false,
        "line_number": 8
      }
    ]
  },

Hook: detect-secrets-hook -v test.yaml --disable-filter detect_secrets.filters.gibberish.should_exclude_secret
Output:
[scan]	INFO	Checking file: test.yaml
ERROR: Potential secrets about to be committed to git repo!

Secret Type: Secret Keyword
Location:    test.yaml:8

Possible mitigations:
  - For information about putting your secrets in a safer place, please ask in
    #security
  - Mark false positives with an inline `pragma: allowlist secret`
    comment

If a secret has already been committed, visit
https://help.github.com/articles/removing-sensitive-data-from-a-repository

Hi @jpdakran
I am using pre-commit hook, like:
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args:
          - --baseline=.secrets.baseline

It happened when I initially added new yml file.

@jpdakran yes, it does use that. As you can see in my original post, I have x-common-variables: &common-variables. And then use it as <<: *common-variables or as environment: *common-variables.


gsap animations added

resolved #543
Description👨💻
Added gsap animations to the components and homepage
Type of change📄

[] New feature (non-breaking change which adds functionality)

Checklist✅

[] My code follows the style guidelines of this project
[] I have performed a self-review of my own code
[] I am an Open Source Contributor

https://github.com/Rakesh9100/Beautiify/assets/124780421/3b7b1257-3d8f-4ba5-8451-ec7a3003a270

We don't need this much animations now. Pls work on other issues @JATIN0926


Project list reflects mainnet in testnet

Projects are currently queried using the Juicebox mainnet subgraph. We don't have a subgraph deployed to any testnets, but it shouldn't be too much work if it's necessary. An easier workaround might be to add a case in the Projects hook for when the user isn't connected to mainnet.

What is the level of effort for this (adding testnet subgraph)? I think it should be included in v1 @mejango after WikiToken fiasco.

Ah it is included! Great

@odd-amphora it'll require:

A subgraph to be created, defined, and deployed for each testnet. Each subgraph definition should be the same as the subgraph for mainnet, just with different contract addresses
A workflow that streamlines upgrading the testnet subgraphs alongside the mainnet subgraph
A pattern for the UI to read from the correct subgraph based on the connected network


Vim support

Any plans to support Vim?

i mean it's just a proxy. what stops you from modifying the vim plugin to make it use your endpoint instead of the official one


error in my own data

hi，
when using my own data, one error occured.
File "../../lib/det_opr/fpn_roi_target.py", line 47, in fpn_roi_target
fg_mask = fg_mask.reshape(-1, top_k)
RuntimeError: shape '[-1, 2]' is invalid for input of size 2001
I check the code and cannot find where to modified.

It looks like that you have some training pictures with only one ground truth. Modify the number of ground truth could solve the problem.
For example, in dataset.py, you could simply modify the "nr_gtboxes" to 2 if "nr_gtboxes == 1"(this is equivalent to using zero box to pad the ground truth).


[CWS] add "pattern -> glob" conversion on windows paths

What does this PR do?
On linux paths evaluation are done through the "symlink" operator override, which delegates to the glob cmp operator override. This allows us to convert pattern to glob and support **/* notation for paths.
This conversion was not done on windows (especially for create.file.path). This PR fixes this.
Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


fix: remove node driver registrar lifecycle hook

was causing /bin/sh not found error
new node driver registrar version automatically removes the socket before terminating

Problem
We see the following error message every time csi driver pod restarts
"Dec  6 18:33:03 ip-xxx-xx-x-xx kubelet: I1206 18:33:03.442938    4937 handlers.go:67] Exec lifecycle hook ([/bin/sh -c rm -rf /registration/csi-image.warm-metal.tech /registration/csi-image.warm-metal.tech-reg.sock]) for Container \"node-driver-registrar\" in Pod \"csi-image-warm-metal-p9zzf_kube-system(f77a9f24-2f8a-46f6-a413-c6f1bfa7ea83)\" failed - error: command '/bin/sh -c rm -rf /registration/csi-image.warm-metal.tech /registration/csi-image.warm-metal.tech-reg.sock' exited with 126: , message: \"OCI runtime exec failed: exec failed: unable to start container process: exec: \\\"/bin/sh\\\": stat /bin/sh: no such file or directory: unknown\

Solution
This problem happens because node-driver-registrar does not have /bin/sh in it because it uses distroless image. This problem should happen every time warm metal pod shuts down.
node-driver-registrar versions < v2.0.0-rc1  don't remove the socket (/registration/csi-image.warm-metal.tech and /registration/csi-image.warm-metal.tech-reg.sock) automatically and we had to use the lifecycle hook.  Our current warm-metal chart in master uses v2.8.0 version of node-driver-registrar which automatically removes the sockets for us (https://github.com/kubernetes-csi/node-driver-registrar/issues/21#issuecomment-517519504). Hence, we don't need the lifecycle hook anymore.
Related

https://github.com/rook/rook/issues/4427
https://github.com/cert-manager/csi-driver/issues/109
https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues/747

Checks
Helm lint passes without any issues:

We need another PR to update our node-driver-registrar version in the installer and samples from v1.1.0 to v2.8.0.
More info on the installer: https://github.com/warm-metal/csi-driver-image/tree/master#installation

We need another PR to update our node-driver-registrar version in the installer and samples from v1.1.0 to v2.8.0.
More info on the installer: https://github.com/warm-metal/csi-driver-image/tree/master#installation

Could we update them in this PR itself?

We need another PR to update our node-driver-registrar version in the installer and samples from v1.1.0 to v2.8.0.
More info on the installer: https://github.com/warm-metal/csi-driver-image/tree/master#installation

Could we update them in this PR itself?

I think it could be a change that can be handled in a separate PR because the change is related to the installer while this PR is more concerned with the chart. Ideally, it would be nice to have both the changes in the same PR but I think we can split the changes into 2 PRs. Let me know what you think.

I think it could be a change that can be handled in a separate PR because the change is related to the installer while this PR is more concerned with the chart. Ideally, it would be nice to have both the changes in the same PR but I think we can split the changes into 2 PRs. Let me know what you think.

Yeah, I think we should fix it in a separate PR. Could you please create an issue to update the installer?

@vadasambar we should be updating our master with this change soon. Could you please update this PR and get it ready for review again?

@vadasambar we should be updating our master with this change soon. Could you please update this PR and get it ready for review again?

Will do and mention you here again. Thanks for the reminder.

@mugdha-adhav updated the PR but forgot to mention you. Can you take a look? I think the PR is ready for review.

Could you please also remove the remaining references for the hook?
And also could we update the Makefile and Chart.yaml with v1.0.1 so that we don't need another PR for releasing this change?

The PR looks good. 👍🏼


Validation for v2 services

This handles all validation for v2 services except for service constraints, which is handled by #358. This does not handle validation for the volumes and network key.
To make this much easier to implement, I modified the v2 schema from Docker Compose so that the root is the services key. Most of the earlier error message generation makes this assumption and refactoring this would be a large effort.
I also had to remove one instance of "additionalProperties": false from the v2 schema since it seemed to cause an error in gojsonschema.
This does a little refactoring around how the schemas are loaded, but I think it can still be improved and custom schemas still cannot be used.
#357

LGTM 🐸
Something weird on the CI, tested locally, it's green :)


TVer.jp broken

Checklist

[x] I'm reporting a broken site support
[x] I've verified that I'm running youtube-dl version 2021.12.17
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar issues including closed ones

Verbose log

youtube-dl https://tver.jp/episodes/epwkkm1yzt
[generic] epwkkm1yzt: Requesting header
WARNING: Falling back on generic information extractor.
[generic] epwkkm1yzt: Downloading webpage
[generic] epwkkm1yzt: Extracting information
ERROR: Unsupported URL: https://tver.jp/episodes/epwkkm1yzt
elwoodchu@M1-Mac-mini video %
elwoodchu@M1-Mac-mini video %
elwoodchu@M1-Mac-mini video % youtube-dl -v https://tver.jp/episodes/epwkkm1yzt
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://tver.jp/episodes/epwkkm1yzt']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
[debug] Git HEAD: 5f5af4324
[debug] Python version 3.10.2 (CPython) - macOS-12.3.1-arm64-arm-64bit
[debug] exe versions: ffmpeg 5.0, ffprobe 5.0, rtmpdump 2.4
[debug] Proxy map: {}
[generic] epwkkm1yzt: Requesting header
WARNING: Falling back on generic information extractor.
[generic] epwkkm1yzt: Downloading webpage
[generic] epwkkm1yzt: Extracting information
ERROR: Unsupported URL: https://tver.jp/episodes/epwkkm1yzt
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/YoutubeDL.py", line 815, in wrapper
    return func(self, *args, **kwargs)
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/YoutubeDL.py", line 836, in __extract_info
    ie_result = ie.extract(url)
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/extractor/common.py", line 534, in extract
    ie_result = self._real_extract(url)
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/extractor/generic.py", line 3489, in _real_extract
    raise UnsupportedError(url)
youtube_dl.utils.UnsupportedError: Unsupported URL: https://tver.jp/episodes/epwkkm1yzt

Description

After TVer.jp is revamped on 1 Apr 2022, the TVer plugin can no longer work as described.

[x] I've searched the bugtracker for similar issues including closed ones

Apparently not, or you would have found #30798.


Adding cookie header support to messages

Decided to go a different direction as per our discussion, so closing this.


Brush the unicorn's mane

lalalala #task

NOPE. NO. NOPE. NUH UH.

I'm going to take this to be a task about documentation, and leave it open :)
Did you have other plans, or mind if I change the title?


update from rt-thread 2020-11-09

拉取/合并请求描述：(PR description)
[
这段方括号里的内容是您必须填写并替换掉的，否则PR不可能被合并。方括号外面的内容不需要修改，但请仔细阅读。
The content in this square bracket must be filled in and replaced, otherwise, PR can not be merged. The contents outside square brackets need not be changed, but please read them carefully.
请在这里填写您的PR描述，可以包括以下之一的内容：为什么提交这份PR；解决的问题是什么，你的解决方案是什么；
Please fill in your PR description here, which can include one of the following items: why to submit this PR; what is the problem solved and what is your solution;
并确认并列出已经在什么情况或板卡上进行了测试。
And confirm in which case or board has been tested.
]
以下的内容不应该在提交PR时的message修改，修改下述message，PR会被直接关闭。请在提交PR后，浏览器查看PR并对以下检查项逐项check，没问题后逐条在页面上打钩。
The following content must not be changed in the submitted PR message. Otherwise, the PR will be closed immediately. After submitted PR, please use a web browser to visit PR, and check items one by one, and ticked them if no problem.
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):

[ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
[ ] 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

[ ] 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
[ ] 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
[ ] 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
[ ] 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
[ ] 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
[ ] 本拉取/合并请求代码是高质量的 Code in this PR is of high quality

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 18 committers have signed the CLA.:x: DavidLin1577:x: luhuadong:x: GFWisshit:x: egbert-h:x: wosayttn:x: z14git:x: mysterywolf:x: bigmagic123:x: zhangsz0516:x: BernardXiong:x: supperthomas:x: thread-liu:x: SimpleInit:x: xckhmf:x: Dozingfiretruck:x: balanceTWK:x: chenyingchun0312:x: qiyongzhong0You have signed the CLA already but the status is still pending? Let us recheck it.


⚠ Bofrost.fr has degraded performance

In e8420e7, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 930 ms

Resolved: Bofrost.fr performance has improved in fdbba11.


JavaScript assets are not initialized if there are only inline scripts

I'm using the grav-ganalytics plugin to handle GoogleAnalytics for a site without any JavaScript code. This plugin use the onAssetsInitialized  event to add inline javascript so I expected that the following code in my site header would be sufficient to make the plugin work:
{{ assets.js() }}

However, this did not render any JavaScript at all. From further investigation I found that it did not render any JavaScript registered using assets.addInlineJS() unless I included a call to assets.addJs() somewhere in the theme. As a workaround I'm currently registering a dummy script:
{% do assets.addJs('dummy', { group: 'dummy' }) %}
{{ assets.js() }}

Adding a dummy script works for now, but I assume this is a bug?

Yes it's a known issue, already fixed in develop by https://github.com/getgrav/grav/commit/492b290845551c7800fa43979622ece26c813293, will be in the next release :+1:


Calulate_frequency.py file

Using this code, what frequency do you guys have got it?

Please check the ipynb file

@s4il3sh The frequency of the peak is approximately 0.00048828125 Hz


Remove Frontend JSON API

In order to remove Frontend's JSON API, we have deleted the ApiRedirectable module and references to it.
https://trello.com/c/7IRxAVoJ/688-retire-frontend-s-json-api
Paired with @cbaines

There's a line in the routes.rb file that looks like it could be removed too?

There's a line in the routes.rb file that looks like it could be removed too?

Good spot - now removed 🎉

do we still need the help.json,  licence-generic.json and the pay-bear-tax.json fixtures?

@brenetic

do we still need the help.json, licence-generic.json and the pay-bear-tax.json fixtures?

I tried deleting help.json but it broke tests related to rendering the help page.  pay-bear-tax.json and licence-generic.json did not break tests however so those are now deleted 👍


chore: upgrade to node lts (v18) [EXT-4812]

deprecate v14 and v16 CI workflows & add v20
specify v18 in engines in package.json

@jjolton-contentful we might want to make this release a new major version. If you add BREAKING CHANGE in the squashed commit description the semantic-release package should pick that up and create a v2 of this package
thoughts @contentful/team-developer-experience ?

@jjolton-contentful we might want to make this release a new major version. If you add BREAKING CHANGE in the squashed commit description the semantic-release package should pick that up and create a v2 of this package
thoughts @contentful/team-developer-experience ?

I wasn't sure but saw this https://stackoverflow.com/a/66289428. Given that, I think you're totally right @t-col


Can't specify CLI options

I was tring to debug a CLI app, but it required CLI options and there doesn't seem to be a way to specify them right now.

Here's the CLI usage info: https://rudjigames.github.io/MTuner/command_line/
Anything other than this you're trying to do?


Conflicting TBS Error Codes

Hi,
Could you clarify the conflicting error codes in this TBS documentation:
https://docs.microsoft.com/en-us/windows/desktop/TBS/tbs-return-codes
Thanks

@ginami Could you follow up this question?

Hi @quinnmagendanz -- thank you for your feedback! We're investigation this issue.


[SFAZRG] Zorgon - Module crashes when entering character name

Module Information

Identifier: SFAZRG
Module Name: Zorgon
Version: unknown

Describe the bug
Module crashes when entering character name
To Reproduce
Steps to reproduce the behavior:

Load Zorgon module
Enter module from MBBSEmu menu
Enter character name

Expected behavior
Creates character and allows you to play game
Screenshots
Unhandled exception. System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'Unable to locate FFFF:0039')
   at MBBSEmu.Memory.MemoryCore.GetWord(UInt16 segment, UInt16 offset)
   at MBBSEmu.CPU.CpuCore.GetOperandValueUInt16(OpKind opKind, EnumOperandType operandType)
   at MBBSEmu.CPU.CpuCore.Tick()
   at MBBSEmu.HostProcess.ExecutionUnits.ExecutionUnit.Execute(IntPtr16 entryPoint, UInt16 channelNumber, Boolean simulateCallFar, Boolean bypassState, Queue`1 initialStackValues, UInt16 initialStackPointer)
   at MBBSEmu.Module.MbbsModule.Execute(IntPtr16 entryPoint, UInt16 channelNumber, Boolean simulateCallFar, Boolean bypassSetState, Queue`1 initialStackValues, UInt16 initialStackPointer)
   at MBBSEmu.HostProcess.MbbsHost.WorkerThread()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

Software Information:

OS: Windows 2019 Server Standard
Telnet Client: NetRunner

This is a reference to MAJORBBS.55 which is ACCBB, which according to the documentation is a reference to the User Account Database. I BELIEVE this is BBSUSR.DAT for MajorBBS and Worldgroup <= 2.0
We'll need to create a new copy of this file using BUTIL and include it with the package same as GENBB. The only additional logic we'll need to also account for is when a new user signs up/is added to the system, we'll need to insert the record into this database as well.

When Registered, Mutants! for Major BBS/Worldgroup also requires ACCBB to lookup the MutantLink user.


Add support for multiple config files

First pass at the merge; currently it can merge the following scenario.
Given the following files:
# initial-config.yml
checks:
  file:
    - name: '[FILE] Illegal files'
      path: web/sites/default/files
      disallowed-pattern: '^(adminer|phpmyadmin|bigdump)?\.php$'

# config-override.yml
checks:
  file:
    - name: '[FILE] Illegal files'
      path: ./

Running go run . -f initial-config.yml -f config-override.yml --dump-config will provide the following config:
project-dir: /Users/yusuf/projects/shipshape
fail-severity: high
checks:
  file:
    - name: '[FILE] Illegal files'
      severity: normal
      path: ./
      disallowed-pattern: ^(adminer|phpmyadmin|bigdump)?\.php$

Note: I did some major refactoring:

Broke out the code for each struct in its own file
Added a check suffix to the check files - a future refactoring would be to move the checks out into a separate directory altogether
In the tests, I'm moving away from using Ensure* and the like, to instead use assert.*

Still a work in progress, and the next step is to allow the following config override to work:
checks:
  file:
    - path: ./

The intention would be to replace the path for all file checks in the config.

The merge is now working as required; given the following files:
# initial-config.yml
checks:
  file:
    - name: '[FILE] Illegal files'
      path: web/sites/default/files
      disallowed-pattern: '^(adminer|phpmyadmin|bigdump)?\.php$'

# config-override.yml
checks:
  file:
    - path: ./

Running go run . -f initial-config.yml -f config-override.yml --dump-config will produce the following config:
project-dir: /Users/yusuf/projects/shipshape
fail-severity: high
checks:
  file:
    - name: '[FILE] Illegal files'
      severity: normal
      path: ./
      disallowed-pattern: ^(adminer|phpmyadmin|bigdump)?\.php$


No built app.js on Windows 10

On Windows 10 in node v6.2.2 and npm v3.9.5, I followed the getting started instructions:

jumpsuit new myProjectName
cd myProjectName
jumpsuit watch

When browsing to localhost:8000 address, however, I get an empty, dark blue page.  Opening the web console shows the following error message:
GET http://localhost:8000/app.js [HTTP/1.1 404 Not Found 4ms]
There is no app.js file anywhere other than the src folder.

Hm, that's weird. Does the initial build process finish? (It should show a build time in milliseconds). And does anything else exist in your dist folder (app.css, etc.)?

Yep, here's what I see, when running it in the git shell:
~/Documents/src/jumpsuit/contraction-timer
$ jumpsuit watch
<...jumpsuit ascii art...>
▸   running at http://localhost:8000
✓ (24ms)
▸   building... ✓ (894ms)

The dist folder contains app.css, index.html, and nothing else.

Yeah it's not even building the js--that should make the initial build time at least 4 or 5 seconds. Can you confirm there's a jumpsuit.config.js in the folder you're running the command in?

Yeah, I believe it's just the standard jumpsuit.config.js:
$ cat jumpsuit.config.js
var fs = require('fs')
var path = require('path')
var stylus = require('stylus')
var nib = require('nib')

var stylusEntry = path.resolve('src/app.styl')

module.exports = {
  styles: {
    extensions: ['.css', '.styl'],
    action: buildStyles
  }
}

function buildStyles () {
  return new Promise(function (resolve, reject) {
    stylus.render(fs.readFileSync(stylusEntry, 'utf8'), {
      'include css': true,
      'hoist atrules': true,
      compress: process.env.NODE_ENV === 'production',
      paths: [path.resolve('src')],
      use: nib()
    }, function (err, css) {
      if (err) reject(err)
      else resolve(css)
    })
  })
}

Not sure if this is related, but jumpsuit build gives me the following in red, and no other output:
▸   Source and destination must not be the same.

▸   Source and destination must not be the same.

Yeah that means something is going wrong in the browserify build. I swear
I've seen that before though. Have you tried deleting your project and
starting fresh again? Uninstalling and reinstalling the cli?
On Sun, Aug 7, 2016 at 7:03 PM geekoftheweek<EMAIL_ADDRESS>wrote:

Not sure if this is related, but jumpsuit build gives me the following in
red, and no other output:
▸   Source and destination must not be the same.
▸   Source and destination must not be the same.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jumpsuit/jumpsuit/issues/26#issuecomment-238121149,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFUmCb_YkAo3cX4Zn0SD6_kIDynxeF9jks5qdoB0gaJpZM4Jeker
.

We just pushed a new version with some updated dependencies which may or may not be the culprits.  npm install -g jumpsuit to update, and try the getting started instructions again.

@geekoftheweek Any luck?

I apologize for the delay. I will be able to check by this time tomorrow,
and will follow up here.
On Mon, Aug 8, 2016, 3:41 PM Tanner Linsley<EMAIL_ADDRESS>wrote:

@geekoftheweek https://github.com/geekoftheweek Any luck?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jumpsuit/jumpsuit/issues/26#issuecomment-238350735,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbGupTvzRnv2UcYhu-diezJG9c6l7uQks5qd4T8gaJpZM4Jeker
.

I've uninstalled & reinstalled jumpsuit-cli (now running v0.7.6), but I'm still getting the same behavior.  On my other test system (running OSX) it continues to work fine -- but still no luck on Windows 10.  Does jumpsuit-cli create log files somewhere that might be useful?

Same here, installed a ubuntu partion, works like a charm there, but not on my win10 machine

According to Stack Overflows 2016 developers server, this affects 20% of developers.
Just sayin' :)
http://stackoverflow.com/research/developer-survey-2016

We will try to get to this issue soon. We don't have easy access to Windows machines to debug, so if anyone wants to take a shot at a PR who has a PC, that would be awesome.

I took a look at it, but I'm assuming that this code is a babel compile version or something since it is totally incomprehensible.
The main problem that I could see, (did get it to build, but not to serve) is that all the path functions will return you win32 paths using double backslashes (\) while all glob functions will return forward slashes (/) in the path names.
Using these 2 incompatible things there is at least one place in the code that is using string comparison on those two types of paths. Also in one place there is a regex function, that for some reason will always fail if you feed it a win32 double backslash path.
The double backslash will also fail, when you turn the paths of the files into imports, converting them to string will take them from double backslashes to single backslashes that are then converted into escape characters meaning that a path to a file c:\project\src\screens\example.js will give out an error like "cprojectsrcscreensexample" not found.
I will take a closer look, but feel I'm severely under qualified.

That's actually very helpful.  Keep going, I don't think you're
underqualified at all!
On Thu, Sep 8, 2016 at 9:30 AM Jón Hallur Haraldsson <
<EMAIL_ADDRESS>wrote:

I took a look at it, but I'm assuming that this code is a babel compile
version or something since it is totally incomprehensible.
The main problem that I could see, (did get it to build, but not to serve)
is that all the path functions will return you win32 paths using double
backslashes () while all glob functions will return forward slashes (/) in
the path names.
Using these 2 incompatible things there is at least one place in the code
that is using string comparison on those two types of paths. Also in one
place there is a regex function, that for some reason will always fail if
you feed it a win32 double backslash path.
The double backslash will also fail, when you turn the paths of the files
into imports, converting them to string will take them from double
backslashes to single backslashes that are then converted into escape
characters meaning that a path to a file c:\project\src\screens\example.js
will give out an error like "cprojectsrcscreensexample" not found.
I will take a closer look, but feel I'm severely under qualified.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jumpsuit/jumpsuit/issues/26#issuecomment-245636669,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFUmCR1Huj4bjAZPc5D6LSWmxkJ2CAN7ks5qoCoGgaJpZM4Jeker
.

@jsonmaur I have a Windows 10 pro 64 bit, Node v 4.2.4 Npm v  3.8.3
npm install -g jumpsuit-cli ran without error, one warning for fsevents not compatible (wich is expected)
jumpsuit new jumpsuit ran without error
jumpsuit watch is stuck on the building message.
`E:\Projects>cd jumpsuit && jumpsuit watch
_                       _ _
|| _ _____ ___ ___ _ || |_
| | | |     | . |_ -| | | |  |
| |||||  |||||
|_|         ||
▸   running at http://localhost:8000
✓ (25ms)
▸   building... ✓ (828ms)`
I would say the problem still exists on windows.

@geekoftheweek  -> Same here, stuck at
     _                       _ _
    |_|_ _ _____ ___ ___ _ _|_| |_
    | | | |     | . |_ -| | | |  _|
   _| |___|_|_|_|  _|___|___|_|_|
  |___|         |_|

▸   Source and destination must not be the same.

▸   Source and destination must not be the same.

when on OSX same config is working fine, i use path at config.

Fixed via https://github.com/jumpsuit/jumpsuit/pull/38


Windows 10  Word Testing - No handle to identify certain objects

It might just be me being inexperienced with the framework, but I tried the following for Office 2016 Word App:
// FindElementByAccessibilityId - AutomationId empty
// FindElementByClassName - ClassName is the same for all buttons
// FindElementById - RuntimeId is dynamic, new with every restart
// FindElementByName - Name is "Close", element is not found with this name
// FindElementByTagName - LocalizedControlType is Button, which is also the same for all buttons
Could you advice me how I can access elements in MS Word?
Thank you.
Christian

Hi @chrber if you are writing a test in C# using the Appium .Net Driver nuget package, you can use the WindowsDriver class to create the session.  With that session you can use FindElementByAccessibilityId and it should work.
Watch for getting attached to splash screens - if you aren't finding anything in your session you may need to create a separate desktop session and find the Word window that you're testing.  A desktop session is created this way:
DesiredCapabilities desktopCapabilities = new DesiredCapabilities();
desktopCapabilities.SetCapability("app", "Root");

I use Java 8 to develop. I have a running session and I can manipulate things with other apps (e.g. Notepad, and calculator). My initial post should be read in a way that I tried all of the methods and the part behind the dash states the results. I use inspect to check for the values in the required field. So I have no problem using the framework, but a very specific problem with a window in the Word application. Specifically the close button in this popup does not have a value in the AutomationId field and the other problems I stated behind the dashed.

Regarding "Specifically the close button in this popup"
Which popup in particular?  Word is big :)

Let's take Office 2016, the Font Ribbon, when you click in the lower right corner and you get the extended Font popup. There I would like to click the "Cancel" Button.
The following can not be used to identify the object (at least looking at inspect)

AutomationID, because does not exist for this button
ClassName
RuntimeID, because it  changes with every startup of the program
Name, is set, but since, as you say: "Word is big", this does not uniquly identify the button
LocalizedControlType is Button

Am I missing something or is inspect not showing everything, is there a better way?

You can locate the specific button by traversing the tree you see in inspect.exe.
This will get the Font windows cancel button:
var cancelButton = session
    .FindElementByClassName("OpusApp")
    .FindElementByXPath("/Window/Window[@ClassName=\"bosa_sdm_msword\"]/Button[@Name=\"Cancel\"]");
cancelButton.Click();

Assuming you are interacting with the Word and Font windows multiple times it is best to locate key elements and use them as a root when locating other elements, as below:
var wordApp = session.FindElementByClassName("OpusApp");
var fontWindow = wordApp.FindElementByClassName("bosa_sdm_msword");
var cancelButton = fontWindow.FindElementByName("Cancel");
cancelButton.Click();

Hi @chrber,
As @stockwep suggested, finding nested element by locating the parent node first and work your way through works very well. When you get to the point that you can no longer specify the target element without ambiguity, you can use XPath or finding multiple elements to select the item.
In v1.0-RC release, the element GetAttribute API now supports arbitrary attributes. Thus, you can use any of the attributes shown in inspect.exe to identify your element as well when iterating through the list of elements.

I would suggest not always depend on FindElementByAccessibilityId
Finding element by XPath is the most trusted way.


Release a new docker image with the latest helm-diff

helm-diff v2.9.0+2 adds the --allow-unreleased flag which allows it to diff a release with no prior versions (this addresses #127). It'd be great to build a new version of the docker image that pulls in this new version!

@wendorf Thanks for the feedback and sorry for the late reply!
Recent helmfile docker images should contain helm-diff binaries that supports --allow-unreleased. So, I'm closing this as resolved, but please feel free to reopen if necessary.


Accessibility: EbaySectionNotice section not being announced by screen readers

EbaySectionNotice section region (role="region") is linking to a description empty element( id="section-notice-attention" element only contains a );

The expected behavior is: "The region has an accessible name that it announced when the region is focused." - while currently the region is not announced by screen readers.

Passing the aria-label on the EbaySectionNotice, will add an aria-label to the svg and screen reader will read it properly.


Show the chart title only in saved image (jpeg or png)

I don't found an approach to show the title only in artifact created by saveAsImage toolbox.
I have been search on docs if there is an event/action to see the click on toolbar -> saveAsImage, but I don't had success.
So, it's possible?
We use the latest echarts version.

You should create a custom feature (doc: feature) rather than get the event, because even if you can get the event, the image has already been saved and there is no use to update title.
So you should use a custom feature, and in the onclick callback, call chart.setOption to add title and then chart.getDataURL() to get the image in base64 format.


Fixed Correct version in commands

Fixed #576

Automated message from Dropbox CLA bot
@kunall17, it looks like you've already signed the Dropbox CLA. Thanks!

Would love to see an alternative solution that addresses my comment in #576 ...

Awesome, thanks for doing this @kunall17!  Merged, after expanding the commit message to explain a bit more what's going on and marking it with Fixes #576 so it'd auto-close that bug.


Add pooled accounts

This is branched from the centos support.

Wait; I'll resend another patch for this, since this was branched on the other branch.

OK. I am actually in progress of testing this.

Yes, but I found that many of the changes that you fixed are still in this branch; and I think the pooled account changes are merely documentation, since they automatically come with the newest version of feudal.
Maybe we should one day depend on fixed versions in the requirements.txt


UPSTREAM_TRANSPORT_FAILURE_REASON not populated when tls handshake fails with unsupported cipher suites

Title: UPSTREAM_TRANSPORT_FAILURE_REASON not populated when tls handshake fails with unsupported cipher suites
Description:
We deployed an updated envoy image yesterday, including a version change from 1.16 to 1.18. Following the deployment, envoy started issuing local 503 replies with RESPONSE_CODE_DETAILS of upstream_reset_before_response_started{connection_failure}.
I added upstreamTransportFailureReason: '%UPSTREAM_TRANSPORT_FAILURE_REASON%' to the access logs (json format), but the value was null (formatted for readability):
{
  "resHeaderXEnvoyRatelimited": null,
  "reqHeaderXClientTraceId": null,
  "resBytes": 91,
  "routeName": "default",
  "reqIpTags": null,
  "reqAuthority": "<redacted>",
  "time": "1623785661913",
  "reqId": "58f7854d-a080-418e-b201-5704ea00dd3a",
  "resStatusCode": 503,
  "reqHeaderUserAgent": "curl/7.64.1",
  "timingUpstream": null,
  "upstreamTransportFailureReason": null,
  "resStatusCodeDetails": "upstream_reset_before_response_started{connection_failure}",
  "downstreamRemoteAddress": "<IP_ADDRESS>",
  "reqMethod": "GET",
  "resHeaderXEnvoyOverloaded": null,
  "reqBytes": 0,
  "timingDuration": 50,
  "upstreamHost": "<IP_ADDRESS>:30143",
  "upstreamCluster": "<name>",
  "reqHeaderXForwardedFor": "<IP_ADDRESS>",
  "reqPath": "/",
  "resFlags": "UF",
  "reqHeaderXClntReqUuid": null,
  "reqProtocol": "HTTP/1.1",
  "resHeaderContentType": "text/plain"
}

I set the envoy log-level to trace which produced the following clues:
[2021-06-15 02:55:09.020][40][trace][http] [source/common/http/http1/codec_impl.cc:604] [C0] parsed 111 bytes
[2021-06-15 02:55:09.020][40][trace][connection] [source/common/network/connection_impl.cc:547] [C0] socket event: 2
[2021-06-15 02:55:09.020][40][trace][connection] [source/common/network/connection_impl.cc:656] [C0] write ready
[2021-06-15 02:55:09.044][40][trace][connection] [source/common/network/connection_impl.cc:547] [C1] socket event: 2
[2021-06-15 02:55:09.044][40][trace][connection] [source/common/network/connection_impl.cc:656] [C1] write ready
[2021-06-15 02:55:09.044][40][debug][connection] [source/common/network/connection_impl.cc:665] [C1] connected
[2021-06-15 02:55:09.044][40][trace][connection] [source/extensions/transport_sockets/tls/ssl_handshaker.cc:237] [C1] ssl error occurred while read: WANT_READ
[2021-06-15 02:55:09.060][40][trace][connection] [source/common/network/connection_impl.cc:547] [C1] socket event: 3
[2021-06-15 02:55:09.061][40][trace][connection] [source/common/network/connection_impl.cc:656] [C1] write ready
[2021-06-15 02:55:09.061][40][trace][connection] [source/extensions/transport_sockets/tls/ssl_handshaker.cc:237] [C1] ssl error occurred while read: SYSCALL
[2021-06-15 02:55:09.061][40][debug][connection] [source/common/network/connection_impl.cc:243] [C1] closing socket: 0
[2021-06-15 02:55:09.061][40][trace][connection] [source/common/network/connection_impl.cc:410] [C1] raising connection event 0
[2021-06-15 02:55:09.061][40][debug][client] [source/common/http/codec_client.cc:101] [C1] disconnect. resetting 0 pending requests
[2021-06-15 02:55:09.061][40][debug][pool] [source/common/conn_pool/conn_pool_base.cc:393] [C1] client disconnected, failure reason:
[2021-06-15 02:55:09.061][40][debug][router] [source/common/router/router.cc:1091] [C0][S2192706120000029174] upstream reset: reset reason: connection failure, transport failure reason:
[2021-06-15 02:55:09.061][40][debug][http] [source/common/http/filter_manager.cc:883] [C0][S2192706120000029174] Sending local reply with details upstream_reset_before_response_started{connection failure}

I noticed that there is a debug message in the log which also appears to be missing a value upstream reset: reset reason: connection failure, transport failure reason:
It turns out that the problem was that envoy 1.17 included the removal of weak cipher suites in these issues (ref: https://github.com/envoyproxy/envoy/issues/5401) and the upstream had an old list of allowed ciphers, which were all weak 🤦
I figured this out by searching for "tls" in the version history of the major version releases, finding the relevant PRs, etc.
I would have expected some stat, debug log or the UPSTREAM_TRANSPORT_FAILURE_REASON to indicate something like "TLS handshake failure: no supported ciphers".
Repro steps:
A TLS upstream with no supported ciphers. In my case the upstream had the following cipher suites enabled:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Admin and Stats Output:
These are all the stats after making 3 requests which route to the upstream with unsupported ciphers:
cluster.<name>.circuit_breakers.default.cx_open: 0
cluster.<name>.circuit_breakers.default.cx_pool_open: 0
cluster.<name>.circuit_breakers.default.rq_open: 0
cluster.<name>.circuit_breakers.default.rq_pending_open: 0
cluster.<name>.circuit_breakers.default.rq_retry_open: 0
cluster.<name>.circuit_breakers.high.cx_open: 0
cluster.<name>.circuit_breakers.high.cx_pool_open: 0
cluster.<name>.circuit_breakers.high.rq_open: 0
cluster.<name>.circuit_breakers.high.rq_pending_open: 0
cluster.<name>.circuit_breakers.high.rq_retry_open: 0
cluster.<name>.internal.upstream_rq_completed: 3
cluster.<name>.ssl.connection_error: 0
cluster.<name>.ssl.fail_verify_cert_hash: 0
cluster.<name>.ssl.fail_verify_error: 0
cluster.<name>.ssl.fail_verify_no_cert: 0
cluster.<name>.ssl.fail_verify_san: 0
cluster.<name>.ssl.handshake: 0
cluster.<name>.ssl.no_certificate: 0
cluster.<name>.ssl.ocsp_staple_failed: 0
cluster.<name>.ssl.ocsp_staple_omitted: 0
cluster.<name>.ssl.ocsp_staple_requests: 0
cluster.<name>.ssl.ocsp_staple_responses: 0
cluster.<name>.ssl.session_reused: 0
cluster.<name>.upstream_cx_connect_fail: 3
cluster.<name>.upstream_cx_connect_timeout: 0
cluster.<name>.upstream_cx_destroy_with_active_rq: 0
cluster.<name>.upstream_cx_idle_timeout: 0
cluster.<name>.upstream_cx_protocol_error: 0
cluster.<name>.upstream_cx_total: 3
cluster.<name>.upstream_rq_active: 0
cluster.<name>.upstream_rq_completed: 3
cluster.<name>.upstream_rq_pending_active: 0
cluster.<name>.upstream_rq_pending_total: 3
cluster.<name>.upstream_rq_timeout: 0

Logs:
See description above.

cc @ggreenway

Before I realized support had been dropped, I tried configuring the upstream TLS context to support ECDHE-ECDSA-AES128-SHA. Envoy seems to silently ignore this configuration and falls back to the default. I'd expect a warning if some cipher suites aren't supported and an error if none of them are supported.
transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
    common_tls_context:
      tls_params: {"cipher_suites":["ECDHE-ECDSA-AES128-SHA"]}

Before I realized support had been dropped, I tried configuring the upstream TLS context to support ECDHE-ECDSA-AES128-SHA. Envoy seems to silently ignore this configuration and falls back to the default.

That's very surprising to me. Can you check if there was anything in the logs about this when you ran with that configuration?

 This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/version_history/version_history for details. If continued use of this field is absolutely necessary, see https://www.envoyproxy.io/docs/envoy/latest/configuration/operations/runtime#using-runtime-overrides-for-deprecated-features for how to apply a temporary and highly discouraged override.
 [2021-06-21 17:59:00.974][17][info][main] [source/server/server.cc:350] HTTP header map info:
 [2021-06-21 17:59:00.975][17][info][main] [source/server/server.cc:353]   request header map: 632 bytes: :authority,:method,:path,:protocol,:scheme,accept,accept-encoding,access-control-request-method,authentication,authorization,cache-control,cdn-loop,connection,content-encoding,content-length,content-type,expect,grpc-accept-encoding,grpc-timeout,if-match,if-modified-since,if-none-match,if-range,if-unmodified-since,keep-alive,origin,pragma,proxy-connection,referer,te,transfer-encoding,upgrade,user-agent,via,x-client-trace-id,x-envoy-attempt-count,x-envoy-decorator-operation,x-envoy-downstream-service-cluster,x-envoy-downstream-service-node,x-envoy-expected-rq-timeout-ms,x-envoy-external-address,x-envoy-force-trace,x-envoy-hedge-on-per-try-timeout,x-envoy-internal,x-envoy-ip-tags,x-envoy-max-retries,x-envoy-original-path,x-envoy-original-url,x-envoy-retriable-header-names,x-envoy-retriable-status-codes,x-envoy-retry-grpc-on,x-envoy-retry-on,x-envoy-upstream-alt-stat-name,x-envoy-upstream-rq-per-try-timeout-ms,x-envoy-upstream-rq-timeout-alt-response,x-envoy-upstream-rq-timeout-ms,x-forwarded-client-cert,x-forwarded-for,x-forwarded-proto,x-ot-span-context,x-request-id
 [2021-06-21 17:59:00.975][17][info][main] [source/server/server.cc:353]   request trailer map: 144 bytes:
 [2021-06-21 17:59:00.975][17][info][main] [source/server/server.cc:353]   response header map: 440 bytes: :status,access-control-allow-credentials,access-control-allow-headers,access-control-allow-methods,access-control-allow-origin,access-control-expose-headers,access-control-max-age,age,cache-control,connection,content-encoding,content-length,content-type,date,etag,expires,grpc-message,grpc-status,keep-alive,last-modified,location,proxy-connection,server,transfer-encoding,upgrade,vary,via,x-envoy-attempt-count,x-envoy-decorator-operation,x-envoy-degraded,x-envoy-immediate-health-check-fail,x-envoy-ratelimited,x-envoy-upstream-canary,x-envoy-upstream-healthchecked-cluster,x-envoy-upstream-service-time,x-request-id
 [2021-06-21 17:59:00.975][17][info][main] [source/server/server.cc:353]   response trailer map: 168 bytes: grpc-message,grpc-status
 [2021-06-21 17:59:00.976][17][info][main] [source/server/server.cc:500] admin address: <IP_ADDRESS>:9901
 [2021-06-21 17:59:00.977][17][info][main] [source/server/server.cc:667] runtime: layers:
   - name: base
     static_layer:
       re2:
         max_program_size:
           error_level: 300
 [2021-06-21 17:59:00.978][17][info][config] [source/server/configuration_impl.cc:128] loading tracing configuration
 [2021-06-21 17:59:00.978][17][info][config] [source/server/configuration_impl.cc:88] loading 0 static secret(s)
 [2021-06-21 17:59:00.978][17][info][config] [source/server/configuration_impl.cc:94] loading 16 cluster(s)
 [2021-06-21 17:59:00.998][17][info][config] [source/server/configuration_impl.cc:98] loading 2 listener(s)
 [2021-06-21 17:59:01.006][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.007][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:183] envoy_on_request() function not found. Lua filter will not hook requests.
 [2021-06-21 17:59:01.007][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:183] envoy_on_request() function not found. Lua filter will not hook requests.
 [2021-06-21 17:59:01.008][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.008][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.009][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.015][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.016][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:183] envoy_on_request() function not found. Lua filter will not hook requests.
 [2021-06-21 17:59:01.016][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:183] envoy_on_request() function not found. Lua filter will not hook requests.
 [2021-06-21 17:59:01.016][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.017][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.017][17][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:188] envoy_on_response() function not found. Lua filter will not hook responses.
 [2021-06-21 17:59:01.020][17][info][config] [source/server/configuration_impl.cc:110] loading stats configuration
 [2021-06-21 17:59:01.020][17][info][main] [source/server/server.cc:764] starting main dispatch loop
 [2021-06-21 17:59:01.112][17][info][runtime] [source/common/runtime/runtime_impl.cc:428] RTDS has finished initialization
 [2021-06-21 17:59:01.112][17][info][upstream] [source/common/upstream/cluster_manager_impl.cc:192] cm init: all clusters initialized
 [2021-06-21 17:59:01.112][17][info][main] [source/server/server.cc:745] all clusters initialized. initializing init manager
 [2021-06-21 17:59:01.112][17][info][config] [source/server/listener_manager_impl.cc:888] all dependencies initialized. starting workers
 [2021-06-21 17:59:01.114][17][warning][main] [source/server/server.cc:642] there is no configured limit to the number of allowed active connections. Set a limit via the runtime key overload.global_downstream_max_connections
 {"resStatusCodeDetails":"upstream_reset_before_response_started{connection_failure}","resBytes":91,"reqHeaderXClientTraceId":null,"upstreamHost":"<IP_ADDRESS>:30143","reqPath":"/","userJwtSub":null,"routeName":"webApi.default","resHeaderContentType":"text/plain","resStatusCode":503,"reqHeaderXForwardedFor":"<IP_ADDRESS>","reqAuthority":"<hostname>","timingDuration":39,"reqId":"19b9784c-956e-45f9-a980-3e10dd854526","timingUpstream":null,"downstreamRemoteAddress":"<IP_ADDRESS>","reqMethod":"GET","reqIpTags":null,"reqBytes":0,"time":"1624298353737","resFlags":"UF","resHeaderXEnvoyOverloaded":null,"reqHeaderXClntReqUuid":null,"reqProtocol":"HTTP/1.1","resHeaderXEnvoyRatelimited":null,"reqHeaderUserAgent":"curl/7.64.1","upstreamTransportFailureReason":null,"userJwtJti":null,"upstreamCluster":"<clusterName>"}

This is the cluster configuration:
    - name: <clusterName>
      type: STRICT_DNS
      connect_timeout: 0.5s
      dns_lookup_family: V4_ONLY
      ignore_health_on_host_removal: true
      respect_dns_ttl: true
      lb_policy: RANDOM
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
          common_tls_context:
            tls_params: {"cipher_suites":["ECDHE-ECDSA-AES128-SHA"]}
            validation_context:
              trusted_ca:
                filename: /etc/ssl/certs/ca-certificates.crt
          sni: <hostname>
      load_assignment:
        cluster_name: <clusterName>
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: <hostname>
                      port_value: 30143

I'm running envoy in docker with the envoy-alpine:v1.18.3 image.

Huh, not sure why it's not working as expected. I would have expected to hit this error: https://github.com/envoyproxy/envoy/blob/1aa65ac88e9888127fe795e3ecb4c1bbc36534bf/source/extensions/transport_sockets/tls/context_impl.cc#L134

Before I realized support had been dropped, I tried configuring the upstream TLS context to support ECDHE-ECDSA-AES128-SHA. Envoy seems to silently ignore this configuration and falls back to the default. I'd expect a warning if some cipher suites aren't supported and an error if none of them are supported.
transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
    common_tls_context:
      tls_params: {"cipher_suites":["ECDHE-ECDSA-AES128-SHA"]}

ECDHE-ECDSA-AES128-SHA in the supported list if you are using boringssl. I think the same result in openssl.
But if tls 1.3 is negotiated, this suite is ignored.
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto
(repeated string) If specified, the TLS listener will only support the specified cipher list when negotiating TLS 1.0-1.2 (this setting has no effect when negotiating TLS 1.3).

Huh, not sure why it's not working as expected. I would have expected to hit this error:
https://github.com/envoyproxy/envoy/blob/1aa65ac88e9888127fe795e3ecb4c1bbc36534bf/source/extensions/transport_sockets/tls/context_impl.cc#L134

The portability is decided by the underlying library. either build or link time, you might see NACK LDS or SDS if that suite is not supported along with this exception.
However, if you build with boringssl, that cipher suite is supported.
This log won't be seen upon ssl handshake as per the above NACK


Not able to navigate to other pages

I am not able to navigate to other pages, no matter what i try.
I am using below code to navigate to other pages:

Consumers

Businesses

Need Help?

I have all the three html files in the same directory as the index.html. Any help would be appreciated. Please tell me what am i doing wrong.

Hi @ravishan110 . Could you show us the full source on a repository so we can help you?
It is likely that adding a leading slash could solve the problem. It also depends on wether those files reside within the domain's root folder or if they are on a folder of their own on.


Fix crash issue when unable to find or allocate service

Current mechanism backs off with a hard-coded 5 seconds between
subsequent search attempts (removal of hard-coding is a TODO)
Will attempt the search 3 times before giving up and returning an
HTTP error 404
Resolves #16

@michaelweiyuzhao Not sure if this is an ideal way to fix #16
Was there a reason the original implementation would loop forever?
Also, after calling AddPeer(), why call continue to search again?

Originally I left it in a loop because if it couldn't find a peer or allocate one, then there was something wrong with the system and it didn't matter what the behavior was so that was the easiest thing to do.
The reason it loops again after adding the new entry is added to the peer cache is to make sure the entry actually appears in the peer cache before using it. Now that I think about it, there's a chance due to contention that it's not added in time and a new instance is allocated so that's something that definitely needed to be fixed.
I'll take a look and merge this tonight.

FYI in case you've already pulled this branch, I just did a force push (bad practice, I know).


Add support matrix checks for RKE1 custom clusters

Issue:  [Automation] Support Matrix checks - Automate RKE1 checks

Problem

Currently, we manually perform our support matrix checks. This is tedious because we need to provision each supported RKE1 version for that Rancher release and then check the etcd, canal and flannel versions. We should  have a way to have this automated so that we don't need to manually do this anymore.
Solution

This PR checks the etcd, canal and flannel image versions across each supported K8s version for the release for CNIs canal and flannel.
Testing

Engineering Testing
Manual Testing

Locally tested against v1.26 and v1.25 with canal and flannel; worked as expected.
Automated Testing

Offline Jenkins jobs will be given to the reviewers.

@igomez06 we manually do RKE1 support matrix checks for finding the image versions for etcd, flannel and canal. We do this for each supported K8s version, so it gets to be a pain pretty quick.
I made this into its own file because we don't necessarily want to validate everything that we do in the custom_cluster.go file. Additionally, we don't want to add the image checks as shown in this PR to the custom_cluster.go, as we only do these version checks once every release.

For cross-posting, we are awaiting for PR https://github.com/rancher/rancher/pull/41424 to be merged before merging this one. There is some overlap between the PRs and it will be easier to rebase changes once that PR is merged first.


Publish GitHub releases

We don't currently publish GitHub releases. We should.
Current process
Our release process currently goes:

Make changes with conventional commit
Release author runs yarn release. This bumps all monorepo packages and updates the changeling.
Release author pushes branch up for review
Release is reviewed. Version and changelog can be tweaked at this point.
When release is merged, CI picks up the release:  commit and publishes all packages

Suggestions
There are 2 options that come to mind:

Manually publish the releases
Automate!

If going with automation (my preferred option), we should update the CI that runs on step 5 to create the release via an API and update it with the changelog for that release.
Notes

Steps 1 -> 4 should not change
The release notes are compiled into 1 large CHANGELOG.md when running yarn release. We could either parse these back out of the CHANGELOG, or consider a separate CHANGELOG directory (but retain a CHANGELOG.md in here containing all releases. I think I prefer the former.
The CI is a GitHub workflow

We're currently doing this manually, which is fine for the time being.


Script publisher: Exclude .publish.yml and .invoker_data from scripts uploaded to server

Published as version 0.4


fix(tangle-dapp): Fix liquid staking pools bugs

Summary of changes
Provide a detailed description of proposed changes.

Fixed LS bugs listed below.
Fixed outdated link to token allocation docs page.
Cleaned up explorer URL logic & hooks.

Proposed area of change
Put an x in the boxes that apply.

[x] apps/tangle-dapp
[ ] libs/webb-ui-components

Associated issue(s)
Specify any issues that can be closed from these changes (e.g. Closes #233).

Closes #2616
Closes #2624
Closes #2612
Closes #2626
Closes #2613
Closes #2617
Closes #2621

Screen Recording
If possible provide screenshots and/or a screen recording of proposed change.

Optional Checklist

[x] I have tested the changes locally.
[x] I have added brief documentation/comments to more complex code blocks or logic that isn't immediately clear.
[x] If new components were added, I've also added and verified their different possible states & edge cases (e.g. loading, error, empty).
[x] For UI changes, I've tested the changes on different screen sizes (responsive design).
[x] For UI changes, I've checked both light and dark mode.
[ ] I've checked the console for any errors that might have been accidentally introduced by my changes.
[ ] If important TODOs were left, I've created corresponding issues for them.
[x] If new flows or features were introduced, I've updated, added, or intend to add corresponding documentation including screenshots and/or screen recordings for them on the Webb Docs repository.

Nice let's cut new release!


Verification with Prusti

For the past few months I've been looking at using Prusti to verify the correctness of ibc-rs, in particular the modules and relayer crates. The purpose of this PR is just to share a bit of what I've been able to accomplish so far and explain what an integration would look like. Also please let me know if you have any feedback or questions. This PR is not intended to be merged.
The Prusti verification operates on entire crates, and is done via an external tool. Prusti verification does not require introducing any new dependencies on the project. Specifications can be encoded as attributes that are only enabled when the "prusti" flag is set, i.e. #[cfg_attr(feature="prusti", <spec>)]. The specification syntax is a superset of Rust, with extensions to support forall expressions etc.
However, Prusti does not currently support all Rust language features and datatypes. So, it is also possible to provide different implementations for Prusti verification only (i.e. to work-around unsupported language features), without changing the actual implementation.
The following describes what I've done so far. A large caveat is that verification required changes to the code to remove unsupported features and datatypes; and some parts of the code containing unsupported features were excluded from verification entirely. The code in this PR only includes the added specifications, without the changes, in order to clearly demonstrate the annotation syntax and invariants. As a result, Prusti won't be able to verify the code in this PR; a version that has removed unsupported features is available here. Note that it is still a bit messy.
Verification of Safety Properties
Prusti was able to verify safety properties on the modules and relayer crate, with the caveat the properties may not hold for code unsupported by Prusti.
No function will trigger panic!
For example in context.rs:
#[cfg_attr(feature="prusti", requires(self.max_history_size > 0))]
#[cfg_attr(feature="prusti", requires(target_height.revision_height <= u64::MAX))]
#[cfg_attr(feature="prusti", requires(target_height.revision_number == self.latest_height.revision_number))]
#[cfg_attr(feature="prusti", requires(target_height.revision_height >= self.latest_height.revision_height))]
pub fn with_height(self, target_height: Height) -> Self {
    if target_height.revision_number > self.latest_height.revision_number {
        unimplemented!()
    } else if target_height.revision_number < self.latest_height.revision_number {
        panic!("Cannot rewind history of the chain to a smaller revision number!")
    } else if target_height.revision_height < self.latest_height.revision_height {
        panic!("Cannot rewind history of the chain to a smaller revision height!")
    } else if target_height.revision_height > self.latest_height.revision_height {
        // Repeatedly advance the host chain height till we hit the desired height
        let mut ctx = MockContext { ..self };
        while ctx.latest_height.revision_height < target_height.revision_height {
            ctx.advance_host_chain_height()
        }
        ctx
    } else {
        // Both the revision number and height match
        self
    }
}

The annotations ensure that the function with_height() will not panic, and introduces an obligation on the caller to ensure preconditions are satisfied.
Calls to Option.unwrap and Result.unwrap will not panic
For example, for serialization:
#[cfg_attr(feature="prusti", requires(Hex::upper_case().encode_to_string(data).is_ok()))]
pub fn ser_hex_upper<S, T>(data: T, serializer: S) -> Result<S::Ok, S::Error>
where
    S: Serializer,
    T: AsRef<[u8]>,
{
    let hex = Hex::upper_case().encode_to_string(data).unwrap();
    hex.serialize(serializer)
}

Arithmetic Operations will not overflow
This is useful, for example, operations on Height, to ensure that it is monotonically increasing.
#[cfg_attr(feature="prusti", requires(u64::MAX - self.revision_height >= delta))]
pub fn add(&self, delta: u64) -> Height {
    Height {
        revision_number: self.revision_number,
        revision_height: self.revision_height + delta,
    }
}

#[cfg_attr(feature="prusti", requires(self.revision_height < u64::MAX))]
pub fn increment(&self) -> Height {
    self.add(1)
}

Functional Correctness
It was also possible to prove domain-specific invariants and correctness properties.
Misbehavior Detection
In tendermint.rs we have proven that:

In the event of misbehaviour, the timestamp for the witness header is after the timestamp of all of the supporting headers

The invariant is specified as:
predicate! {
    fn misbehaviour_invariant(m: &MisbehaviourEvidence) -> bool {
    forall(
        |i : usize|
        (0 <= i && i < m.supporting_headers.len() ==>
          get_supporting_header_time(&m.supporting_headers, i) < get_witness_time(&m.misbehaviour)))
    }
}

The witness header is within the trust period

This invariant asserts header_within_trust_period from the Tendermint crate.
Proving these invariants require adding and proving additional invariants of other functions.
Client Keeper
In ibc.rs, we prove that store_client_result in ClientKeeper, will correctly maintain an invariant about the stored client data. This is done out of the codebase, because the separation of ClientKeeper and ClientReader traits.
The client invariant corresponds to:
fn client_invariant(client: &MockClientRecord) {
    match client.client_state {
        Some(cs) =>
            match client.consensus_states.keys().max() {
                Some(max_height) => cs.latest_height() == max_height,
                None => false
            },
        None => client.consensus_states.is_empty()
    }
}

Hi @zgrannan. Thank you for your work here!
Am I correct in understanding that this PR is a proof of concept wrt. Prusti-based testing integration in ibc-rs? Let us know if there are specific topics you'd like us to weigh in or provide feedback.
In particular the panic and arithmetic overflow guards would be very interesting for us, since we had prior experience where this kind of problems can occur and are not always easy to catch (ref #1885 #1555 #1442 #1122).


Crit hack

Make the crit hack work with pyro's flamethrower

as i have said before, no.

why?

(he doesn't know how)


Update or remove apple touch icon

<link rel="apple-touch-icon" href="/img/apple-touch-icon.png">

Uses this image:

which seems like it comes from html5 bootstrap

Removed it


[types] limit nesting of types via state

Motivation
This is an alternative version of what #528 and the previous PR for limitation of nesting of type tags provides.
This approach installs custom serializers at the recursion points of the TypeTag enum. Those serializer use a thread local to track the nesting of the type tag, both for serialization and deserialization.
The usage of a thread local is safe and a common technique to provide extra state for implementations which miss it (e.g. serde). A given thread has a single execution stack and this will always count the depth counter consistently up and down. Because Rust has no exceptions are other exit points, this cannot be corrupted. Possibly, thread locals may cause inefficiency. However, we expect TypeTags to be small (a few constructors, limited nestings).
The technique used for type tags can be generalized for any other recursive type if needed. Eventually, we hope serde will support per-type nesting, and possibly we should talk with the author if we can add it ourselves.
(Write your motivation for proposed changes here.)
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
This uses and passes the tests from #528.

I'll just leave a note:
this is pretty cool and reminds me of back in the days when we had a custom function to serialize/deserialize Move Values and it was few lines of code and easy to understand. The visitor pattern of serde is pretty difficult to follow.
Later there was this push to make everything "pure serde" and that conversation/train was impossible to stop.
The use of thread local storage is difficult to evaluate for me. And of course I wish (as I am sure we all do) that it was easy to pass a custom value on the stack, basically what the visitor pattern allows but without the insanity of the visitor pattern. Anyway, enough of wishful thinking...
With nesting being a global property, a TLS seems fine, not sure that will always be true and that is one place where it could be difficult.
With leaf types (as TypeTag or Move Values) that is also fine, I think.

Do we need to land this change on aptos branch? Also will this be a substitute for #525 and #526 on aptos branch?

This solution seems reasonable to me. Couple of questions about the motivation: I'm assuming that this exists to prevent stack overflows when serializing or deserializing TypeTag's. Is the concern about:

Converting SignatureToken's in the bytecode format into TypeTag's (e.g., to write a value into global storage)
Accepting user-specified TypeTag's as tx inputs (e.g., entry fun pay<T>(amount: u64))
Accepting user-specified TypeTags in read API's (e.g., to simulate the result of a function call)

I'm guessing all of the above, but wanted to know which surfaces I might be overlooking. Also, if it's just (1) (or if we want to prevent runtime failures in the case of (1)), we could think about enforcing this in the file format or verifier.

This solution seems reasonable to me. Couple of questions about the motivation: I'm assuming that this exists to prevent stack overflows when serializing or deserializing TypeTag's. Is the concern about:

Converting SignatureToken's in the bytecode format into TypeTag's (e.g., to write a value into global storage)
Accepting user-specified TypeTag's as tx inputs (e.g., entry fun pay<T>(amount: u64))
Accepting user-specified TypeTags in read API's (e.g., to simulate the result of a function call)

? (I'm guessing all of the above, but wanted to know which I am wrong about + which surfaces I might be overlooking). Also, if it's just (1) (or if we want to prevent runtime failures in the case of (1)), we could think about enforcing this in the file format or verifier.

This is not just about stackoverflows. We can discuss offline. Closing this one, as we have landed this now (with some mods) in aptos branch. Will send another cherrypick PR later.


Error when tmux new a terminal: /root/.tmux.conf:31: usage: new-window

tmux version: tmux 2.7
tmux new -s test
/root/.tmux.conf:31: usage: new-window [-adkP] [-c start-directory] [-F format] [-n window-name] [-t target-window] [command]

Hello @thisjiang,
Thanks for the report. This bug has been introduced by #679.
Support for new-window -e has been added in tmux 3.0.
Can you please upgrade until I figure out if there's a solution?

Can you please try the gh-755 branch?


⚠ Bofrost.es has degraded performance

In e2b2fa1, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1801 ms

Resolved: Bofrost.es performance has improved in 08b6c27.


View CropBox does not handle ViewType.Detail

I just discovered that within the View CropBox node, that it could not handle my detail views.
Upon investigation it seems that the node does not have a condition to catch views of the type ViewType.Detail.

Hi Jake,
Thanks for adding.
I will publish an update to the package.


add resources

added resources for Django, Machine Learning, MongoDB and Python.

Merged. Thank you.