scripts/dts: deprecate DT__BUS

We don't have any uses of this form of define so deprecate it for now.
If needed this should be DT_INST__BUS.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

@avisconti, you might be one of the main users of this.

@erwango @galak
Well, actually I'm missing what this PR is intended for.
Are you going to deprecate DT_ST_LPS22HH_0_BUS_SPI or DT_ST_LSM6DSO_BUS_I2C?
I don't think so, so someone can please explain it in more details?
Thanks

Well, actually I'm missing what this PR is intended for.
Are you going to deprecate for example DT_ST_LPS22HH_0_BUS_SPI or DT_ST_LSM6DSO_BUS_I2C?
I don't think so, so someone can please explain it in more details?
Thanks

This is deprecating the DT_ST_LIS2DH_0_BUS_SPI form only.  There was only one instance which we changed in commit 0a99f53c80edabfb2ecbe31d66332430d9c355f8

This is deprecating the DT_ST_LIS2DH_0_BUS_SPI form only. There was only one instance which we changed in commit 0a99f53

OK, not able to figure out if we will have impacts or not, but I guess that the CI will help us on this.

OK, not able to figure out if we will have impacts or not, but I guess that the CI will help us on this.

@avisconti can you approve this or comment if you want more info/testing?

This is deprecating the DT_ST_LIS2DH_0_BUS_SPI form only. There was only one instance which we changed in commit 0a99f53

@galak
When you say this does it mean that, for example, the DT_ST_LPS22HH_0_BUS_SPI will disappear? How can the driver work then? Maybe I'm not getting the point properly...

This is deprecating the DT_ST_LIS2DH_0_BUS_SPI form only. There was only one instance which we changed in commit 0a99f53

@galak
When you say this does it mean that, for example, the DT_ST_LPS22HH_0_BUS_SPI will disappear? How can the driver work then? Maybe I'm not getting the point properly...

OK, got it now.
We are using always DT_ST_LPS22HH_BUS_I2C type.
I think is fine!

@galak
When you say this does it mean that, for example, the DT_ST_LPS22HH_0_BUS_SPI will disappear? How can the driver work then? Maybe I'm not getting the point properly...

Yes, this define will eventually disappear.  The driver now just uses DT_ST_LIS2DH_BUS_SPI instead.

There is one place where we still use the _0 stuff in ./lis2dh/lis2dh.c:
DT_ST_LIS2DH_0_BUS_SPI
Maybe you may want to correct that one as well.

Fixed in #17457


Create custom view

I created a view but the context load properly, not load the menu bar and  name app
class MyView(BaseAdminView):
base_template = 'xadmin/base_site.html'
@never_cache
def get(self, request, _args, *_kwargs):
context = self.get_context()
return TemplateResponse(self.request, [
'xadmin/views/Welcome.html'
], self.get_context(), current_app=self.admin_site.name)
xadmin.site.register_view(r'^xadmin/welcome/$',MyView, name='welcome')
Any idea?

@javienco  Do you still use xadmin on your project?

@javienco ...I have registered my custom view like this. But how can i generate a menu from this ?


proxy: detect TLS configuration changes using inotify on Linux

This branch adds an inotify-based implementation of filesystem watches
for the TLS config files. On Linux, where inotify is available, this is
used instead of the polling-based code I added in #1056 and #1076.
In order to avoid the issues detecting changes to files in Kubernetes
ConfigMaps described in #1061, we watch the directory containing the
files we care about rather than the files themselves. I've tested this
manually in Docker for Mac Kubernetes and can confirm that ConfigMap
changes are detected successfully.
Note that this currently depends on code added to the inotify crate in
my upstream pull request inotify-rs/inotify#103, rather than the version
on crates.io.
Closes #1061. Closes #369.

@briansmith (et al.) I've rebased this branch onto the latest master, sorry about the briefly messy diff.


Crash after high memory usages

Creating simulations with large amounts of memory can cause a crash without notification.

A meaningful message is displayed to the user.

A meaningful message is displayed to the user.


How set a Navigationbar Customization Globally?

How can i set a customization globally, instead of to do this in every ?
For exemple, i want set gradient background color on navigation on entire app, not just in page A or B on code behind page:

CustomNavigationPage.SetGradientColors(detailPage, Tuple.Create(startColorNavigationBar, endColorNavigationBar));
CustomNavigationPage.SetGradientDirection(detailPage, CustomNavigationPage.GradientDirection.RightToLeft);

Hello, you need to derive your pages from CustomPage and put the related set gradient methods into its constructor before InitializeComponent()


Logic panel: Direct link to the panel doesn't load the chart

"Direct navigation
If you navigate directly to the logic page (i.e. /form-builder/{form_id}/edit/logic or by reloading the page), the flowchart doesn't load"
Participant 1 (English flow) form file in slack

I have narrowed this down to our Content security policy blocking something when this page is loaded directly.
Not sure how to solve yet .

Merged a fix for this.


Vulkan 1.1: Restrictions on mask operand for OpGroupNonUniformShuffleXor

https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/spirvenv.txt#L465

Found in internal Vulkan MR 2971 that this was removed and therefor no need to add

Found in internal Vulkan MR 2971 that this was removed and therefor no need to add


Make signal callable on stable

(Thanks to @matthunz for letting me know about dtolnay's amazing article about derefing to closures on stable!)
This restores the previously unsound implementation of Deref<Target = dyn Fn() -> Ref<'static, T>> on signals which lets you call the signal like a function instead of reading the signal:
fn App(cx: Scope) -> Element {
    let signal = Signal::new("hello world".to_string());
    // You can call signals like functions to get a Ref of their value.
    assert_eq!(&*signal(), "hello world");

    render! {
        "hello world"
    }
}

What's cool about this is that, with #1546 you can now do very simple iters:
for todo in todos().iter() {
    div { "{todo.title}" }
}

Looks good


Support case-insensitive keywords

Signed-off-by: Julius Volz<EMAIL_ADDRESS>

@Nexucis This is the best way I've found to support case-insensitive keywords / contextual keywords so far, based on the new external token specialization features which were just released in lezer: https://lezer.codemirror.net/docs/guide/#external-tokens

This will likely require some changes to the packages using this.

Actually I like it better than the previous version. The usage of the keyword was a bit weird from my point of view.
And I don't think it won't change so many things. I'm just wondering if we still need to export the different list of keyword (in the file promql.terms.js)

Overall awesome work !


margin API will change by March 2024

Hello all,
I would like to ask if you guys are planning to fix the changes for the margin API?
2024-01-09

    According to the [announcement](https://www.binance.com/en/support/announcement/updates-on-binance-margin-sapi-endpoints-2024-03-31-a1868c686ce7448da8c3061a82a87b0c), Binance Margin will remove the following SAPI interfaces at 4:00 on March 31, 2024 (UTC). Please switch to the corresponding alternative interfaces in time:
        POST /sapi/v1/margin/transfer will be removed, please replace with POST /sapi/v1/asset/transfer universal transfer
        POST /sapi/v1/margin/isolated/transfer will be removed, please replace with POST /sapi/v1/asset/transfer universal transfer
        POST /sapi/v1/margin/loan will be removed, please replace with the new POST /sapi/v1/margin/borrow-repay borrowing and repayment interface
        POST /sapi/v1/margin/repay will be removed, please replace with the new POST /sapi/v1/margin/borrow-repay borrowing and repayment interface
        GET /sapi/v1/margin/isolated/transfer will be removed, please replace it with GET /sapi/v1/margin/transfer to get total margin transfer history
        GET /sapi/v1/margin/asset will be removed, please replace with GET /sapi/v1/margin/allAssets
        GET /sapi/v1/margin/pair will be removed, please replace with GET /sapi/v1/margin/allPairs
        GET /sapi/v1/margin/isolated/pair will be removed, please replace with GET /sapi/v1/margin/isolated/allPairs
        GET /sapi/v1/margin/loan will be removed, please replace with GET /sapi/v1/margin/borrow-repay
        GET /sapi/v1/margin/repay will be removed, please replace with GET /sapi/v1/margin/borrow-repay
        GET /sapi/v1/margin/dribblet will be removed, please replace with GET /sapi/v1/asset/dribblet
        GET /sapi/v1/margin/dust will be removed, please replace with POST /sapi/v1/asset/dust-btc
        POST /sapi/v1/margin/dust will be removed, please replace with POST /sapi/v1/asset/dust

    New Endpoints for Margin:
        POST /sapi/v1/margin/borrow-repay: Margin account borrow/repay
        GET /sapi/v1/margin/borrow-repay: Query borrow/repay records in Margin account

    Update Endpoints fpr Margin:
        GET /sapi/v1/margin/transfer: add parameter isolatedSymbol, add response body
        GET /sapi/v1/margin/allAssets: add parameter asset, add response body
        GET /sapi/v1/margin/allPairs: add parameter symbol
        GET /sapi/v1/margin/isolated/allPairs: add parameter symbol

Reference here: https://binance-docs.github.io/apidocs/spot/en/#change-log
Thanks in advance,

Move to https://github.com/binance/binance-connector-python which is the officially supported library now


Observed memory leak problem of re2 NIF library

Hi,
Thanks for the great implementation of Cassandra client! I'm using cqerl for a project to create a timeseries storage service on top of Cassandra, during some stress tests with 100-200 concurrent requests with mixed reads/writes, I found that there is a serious memory leak issue in current master version of cqerl, which is reproducible in different OS platform.
Tested Environments
- Ubuntu 14.04 LTS 64-bit (a VM of 2 vCPU and 4GB RAM)
- Alpine Linux 3.4 64-bit (a Docker container of 1 vCPU and 1GB RAM)

Proof of leak
I used a live memory leak tracking tool called memleax, and found that all leaks refer to the same line of code (re2_match()+825  c_src/re2_nif.cpp:282) in the re2 NIF dependency used in cqerl:
CallStack[15]: may-leak=199 (7960 bytes)
    expired=199 (7960 bytes), free_expired=0 (0 bytes)
    alloc=292 (11680 bytes), free=0 (0 bytes)
    freed memory live time: min=0 max=0 average=0
    un-freed memory live time: max=25
    0x00007fafd21a8750  libc-2.19.so  malloc()+0  /build/eglibc-3GlaMS/eglibc-2.19/malloc/hooks.c:77
    0x00007faf9e3afdad  libstdc++.so  _Znwm()+29
    0x00007faf9e676972  re2_nif.so  _ZN3re26Regexp17ConcatOrAlternateENS_8RegexpOp()+642
    0x00007faf9e69a62a  re2_nif.so  _ZN3re26Regexp10ParseState10DoCollapseENS_8Reg()+394
    0x00007faf9e69a748  re2_nif.so  _ZN3re26Regexp10ParseState13DoVerticalBarEv()+24
    0x00007faf9e69a7f9  re2_nif.so  _ZN3re26Regexp10ParseState13DoAlternationEv()+9
    0x00007faf9e69a829  re2_nif.so  _ZN3re26Regexp10ParseState8DoFinishEv()+9
    0x00007faf9e69d140  re2_nif.so  _ZN3re26Regexp5ParseERKNS_11StringPieceENS0_10()+352
    0x00007faf9e66b9a7  re2_nif.so  _ZN3re23RE24InitERKNS_11StringPieceERKNS0_7Opt()+455
    0x00007faf9e66ce72  re2_nif.so  _ZN3re23RE2C1ERKNS_11StringPieceERKNS0_7Option()+98
    0x00007faf9e669ed9  re2_nif.so  re2_match()+825  c_src/re2_nif.cpp:282
    0x0000000000436370  beam.smp  process_main()+16624
    0x00000000004b4fdf  beam.smp
    0x00000000005b92ab  beam.smp
    0x00007fafd26fb182  libpthread-2.19.so  start_thread()+194  /build/eglibc-3GlaMS/eglibc-2.19/nptl/pthread_create.c:312
    0x00007fafd222047d  libc-2.19.so  clone()+109  ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Please check attachments for full details.
I changed the implementation to replace re2 with built-in Erlang re library, and the memory leaking issue no longer exists. Understood that the original thought of using re2 is to have a more linear worst case (#49) but not sure if it really provides significant performance improvement in current usage of regular expression matching in cqerl.
Suggest to change back to re library before we report and fix the issue to the upstream of re2 NIF library? Thanks!
mem_leak_re2_20160906.txt

Thanks for reporting this @guitarmind!
@lpgauth I'm asking you just because in our initial discussion you suggested it would behave better. Have you ever seen this sort of problem in your high-performance production system?
@bernardd thoughts?

If I had to take a guess, I'd say that that stack trace implies a leak down in the bowels of libre2 somewhere. When building, the NIF wrapper looks for an existing libre2 install and pulls down the latest if it can't find one. That means that if you have old libre2 packages installed, you'd get any bugs they had, while those of us who don't have them installed would be likely to have newer versions that perhaps didn't have those bugs.
It is, of course, possible that it's a bug with the re2 NIF code, but looking through it now I can't see any obvious issues (which is of course zero guarantee that there aren't).
It would be very useful to have a minimal replication case just using re2 - if it's leaking as badly as you say, it should be a pretty simple matter of setting up a loop doing regex matches and watching the memory use explode.

I am experiencing similar issues as posted by @guitarmind. I have yet to track them down, but I guess I will try removing re2 first.

@bkolodziej Good to know that you also encountered similar issue and resolved it by removing re2 usage as well.
As mentioned, it might be reasonable to change back to re library before we report and fix the issue to the upstream of re2 NIF library. My pull request had replaced re2 with Erlang re library and the performance of cqerl in our stress test showed no significant difference.
@matehat @bernardd Do you have any plan to follow up with this issue? Thanks!

I've reported the issue to the google team, and mentioned the maintainer of the erlang driver. Let's see if they can jump and help with that issue.

Commented in https://github.com/google/re2/issues/120.

19 days ago, @bernardd wrote:

It would be very useful to have a minimal replication case just using re2 - if it's leaking as badly as you say, it should be a pretty simple matter of setting up a loop doing regex matches and watching the memory use explode.

Has anyone done this?

Has anyone done this?

@junyer, I did and found a leak. See https://github.com/tuncer/re2/issues/17.

@junyer @tuncer Thanks very much for your help with getting this sorted. Much appreciated.

@matehat @bernardd
A fixed version has been released in tuncer/re2 by @tuncer
Shall we merge it into your forked re2 project?
I found that due to some recent changes in rebar.config.script of in tuncer/re2 the compilation of re2 NIF would fail while running mix compile:
Error evaluating rebar config script  ... : evaluation failed with reason error:{badmatch,undefined} and stacktrace [{erl_eval,expr,3,[]}]
Any dependency defined in the script won't be available unless you add them to your Mix project

Using an older version from matehat/re2 seems fine. Thus you might need to be aware of this before doing merge. Thanks.

@guitarmind, if the rebar.config.script eval failure is reproduceable with rebar, please file a separate ticket with steps to reproduce. If there's a syntax error somewhere, I should have run into it as well.

@tuncer Thanks, I open a new issue #18 in tuncer/re2.

The Elixir mix issue has also been resolved since January 28th. So, if you updated your re2 vsn in the deps, this ticket can be closed as RESOLVED-FIXED.

Thanks @tuncer!


Misc changes to create podman bundle on different arch

As of now CI fails because of following.
$ curl -L https://github.com/coreos/ignition/releases/download/v2.13.0/ignition-validate-x86_64-linux -o ignition-validate
$ ./ignition-validate -h
./ignition-validate: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./ignition-validate)
./ignition-validate: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./ignition-validate)
$ rpm -qa | grep -i glibc
glibc-langpack-en-2.28-164.el8.x86_64
glibc-common-2.28-164.el8.x86_64
glibc-devel-2.28-164.el8.x86_64
glibc-2.28-164.el8.x86_64
glibc-headers-2.28-164.el8.x86_64

https://github.com/coreos/ignition/issues/1311 is recently merged so hopping if there is release soon then it should work as expected.

/retest

I added https://github.com/cfergeau/snc/commit/07c6a4c3a95492263aab49a4463f64b1d8a314ff to uncompress the aarch64 kernel, but I cannot easily test this now.

With the latest changes, I've been able to generate an aarch64 bundle. I'll test it on a m1 soon.

/hold
[Use quay.io/crcont/gvisor-tap-vsock:arm which has aarch64 support](https://github.com/code-ready/snc/pull/503/commits/efe0d9467c4627987e7b72f34a4e2e954f91811f) is aarch64 only, and would break x86_64 bundle generation. I'll file an issue with more details about this.
The other commits in this PR are working on both platforms, so we could merge all of these while we solve the gvisor-tap-vsock image issue, this way we'd be 99% there for aarch64 support.

/unhold
After rebuilding the arm64/amd64 images outside of brew, the latest tag now has a working gvisor-tap-vsock version.


ModsecurityIIS does not pass through POST data to Popular CMS when SecRequestBodyAccess is set to On

MODSEC-414: ModsecurityIIS does not pass through POST data to WordPress/Joomla/Modx (on Admin Panel) when SecRequestBodyAccess is set to On

Fantastic job guys. This fixed my issues with DNN ActionForm.

Closing due to being resolved based on @smytht and @tizzythegrey comments. Thanks.


Unify naming methods into a single method + options builder type

Right now we have a few different methods for getting something name, plus a few different parameters controlling what kind of name you end up getting from it. I think it would be a nice clean up if we had only a single method for getting a name, that took an options type that described what kind of name we wanted. We could make the naming options a builder class. The defaults would be sanem
Imagining something like this:
// Create a name options builder.
item.name()
    // Use namespaces, regardless what the BindgenOptions
    // were configured with.
    .with_namespaces()
    // Do not use mangle the name to avoid Rust keywords.
    .no_rust_mangling()
    // Do not automatically deref this item into its replacement.
    .ignore_replacements()
    // Finish the builder and compute the actual name.
    .get(context)

Details aren't important. What is important is:

Sane defaults based on how BindgenOptions was configured (for example, use whatever option was specified for namespaces by default)

Force individually name options on/off regardless whether BindgenOptions were configured to have that option on/off

Control over whether replacements are taken into account

And we would probably want this single unified naming method to be part of the ItemCanonicalName trait so everything can use it (and maybe drop Item to be just CanonicalName).

I can take it. And it would be good if you give me a little guide where to start.

@impowski, great!
Since I wrote this issue up, the situation has improved a little bit. We've separated getting a name within a namespace from getting a full name including namespaces and potentially namespace mangling.
Right now the naming variations we support are all permutations of

with or without namespace mangling. eg C++'s foo::bar::Baz becomes foo_bar_Baz (ie the within_namespace parameter to Item::real_canonical_name)

for replacement checking vs for code generation (ie the for_name_checking parameter to Item::real_canonical_name)

I would hold off on any hypothetical other naming options until we find a use for them (I have some ideas, but we shouldn't bog ourselves down yet).
So, I suggest we start with something like this:

create a NameOptions builder struct with flags for the options above

make Item::real_canonical_name et al take the options struct as a parameter instead of multiple bool parameters

add convenience methods so we can have usage kind of like the example in the original issue comment

on Item, define fn name(&self) -> NameOptions

on NameOptions, define fn get(&BindgenContext) -> String which calls Item::real_canonical_name

I hope that's enough to get you started, if anything is unclear, don't hesitate to reach out to me :)

This one can be closed I guess


UAT and Sign off

Description
Definition of done

[ ] Understand the current process in place to gather sign off - How often are we showing functionality's to sections?

[ ] when the stories are being designed

[ ] when stories are being developed

[ ] when stories are in staging

[ ] or all of the above?

[ ] Define and publish a quick workflow of how we are collecting feedback and when we expect sections to provide feedback
[x] Ideate if there is a better way to collect section sign off on stories-  Decision logging? Bringing members from sections to story time?

Attachments
title

We now have a story sign off and a customer sign off. Story sign off decision log is included in the cards with the responsible assignee to move the story along.


feat: refactor reset provider

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#208  👈
#207
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @refcell and the rest of your teammates on  Graphite


Report

Describe the bug
A clear and concise description of what the bug is.
Steps To Reproduce
Steps to reproduce the behavior:

...
...
...

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

It looks like you forgot to fill anything in.

Seems this was accidentally opened. Closing. 🙂


Button can't be rendered as it's return type is ReactNode.

[x] I have searched the Issues to see if this bug has already been reported
[x] I have tested the latest version

Steps to reproduce

Create a CRA,
Install flowbite react
Add a button to a page

Current behavior
TS2786: 'Button' cannot be used as a JSX component.
  Its return type 'ReactNode' is not a valid JSX element.
    Type 'undefined' is not assignable to type 'Element | null'.

Expected behavior
To normally render a Button
Workaround
CTRL/CMD+click on Button component will bring you to the .d file, there change the last NodeElement into JSX.Element. After this restart the server
I might fix this bug myself when i have 10 free minutes if noone picks this up before me

What React version are you using?

What React version are you using?

"react": "^18.2.0"
I think the issue is caused by this, but the fix is really fast, just need to change the component return type to JSX.Element

What React version are you using?

"react": "^18.2.0"
I think the issue is caused by this, but the fix is really fast, just need to change the component return type to JSX.Element

Well if you can change it within your project and it works, go for it, but what about @types/react?

I'm facing this issue too.

'Button' cannot be used as a JSX component.
Its return type 'ReactNode' is not a valid JSX element.

This started happening when I updated to version 0.6.0

Hi
I've created today a typescript+react template
 npx create-react-app my-app --template typescript
then followed steps from there  https://www.flowbite-react.com/docs/getting-started/introduction I've installed latest version of  flowbite-react (0.7.3)
I've put a button on my app
import { Button } from 'flowbite-react';

export default function MyPage() {
  return (

      <Button>Click me</Button>

  );
}

and got
TS2786: 'Button' cannot be used as a JSX component.
  Its return type 'ReactNode' is not a valid JSX element.
    Type 'undefined' is not assignable to type 'Element | null'.

Looking into it, will push and release a fix ASAP.

Note that this also affects Dropdown.Item. Regression from #1244.
https://github.com/themesberg/flowbite-react/pull/1244#issuecomment-1991793938

JSX.Element

Yeah Dropdown.Item is broken as well in v0.7.3

PR opened at #1297

The DropDown.Item is not yet fixed, after making modification on my pc changing ReactNode to JSX.Element i can then build on my pc but using GitHub actions or any pipeline is impossible unless its fixed on the npm server,  i hope the administrators can do something about this.

Looks like this library is going to be broken for a while (based on code freeze announcement and the length of time the fix PR has been sitting).
In the meantime, everyone will have to ts-ignore the TS issues to get their build passing 😞

After some tests, if people are on typescript 5.x and above, they should be fine.

I got a dirty solution, until we get it properly working and/or refactor the polymorphic forwarded ref component. Stay tuned.

Fixed by v0.7.4 release.

Hi team I still facing the same issue after upgrade it to v0.7.5

This is my code:
export const TOC = (props: Props) => {
    const { show, onClose } = props;

    return (
        <Modal show={show} onClose={() => onClose()}>
            <Modal.Header>Terms of Conditions</Modal.Header>
            <Modal.Body>

                    some toc

            </Modal.Body>
            <Modal.Footer>
                <Button>I accept</Button>
                <Button color="gray">
                    Decline
                </Button>
            </Modal.Footer>
        </Modal>
    )
}

this is my dependencies in package.json:
"dependencies": {
    "@reduxjs/toolkit": "^2.2.1",
    "@testing-library/jest-dom": "^5.17.0",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^13.5.0",
    "@types/jest": "^27.5.2",
    "@types/node": "^16.18.89",
    "@types/react": "^18.2.66",
    "@types/react-dom": "^18.2.22",
    "axios": "^1.6.8",
    "flowbite": "^2.3.0",
    "flowbite-react": "^0.7.5",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-redux": "^9.1.0",
    "react-router-dom": "^6.22.3",
    "react-scripts": "^5.0.1",
    "sweetalert2": "^11.6.13",
    "typescript": "^4.9.5",
    "web-vitals": "^2.1.4"
  }

and in node_modules, flowbite-react already change to 0.7.5

anyone facing the same issue after upgrading?

awesome, it works for me after I restart my VSCode


Selecting Mash in normal mode (not Fast Mode) doesn't trigger the selection modal

Found by reddit user /u/Hymneth: https://www.reddit.com/r/grandorder/comments/1ge39an/a_fun_easy_way_to_shareshow_off_your_roster_fgo/lub9lyr/
When selecting Mash in normal mode (Fast Mode deactivated), clicking/tapping on Mash to select her causes an error in the console due to trying to alter the value of an unknown/undefined variable.

Fixed by 65cb93d1e6498ddad1a43b0170844471d98d6857, closing issue.


Connectors are unarchived and do not necessarily have the correct permissions

Deploying a new connector via archive does not necessarily set the correct permission automatically.
When you have a strong umask for your ansibe user, you might run into issues.
suggested solution:
Add concret permissions in the unarchive task.

Is this what you are looking for: https://github.com/confluentinc/cp-ansible/pull/368

Wow I just saw your PR lol!
I actually assumed you knew the fix to this as I was doing it @Fobhep

oha sorry :D

Mine was second, don't change your process!

@Fobhep this can be closed right? I merged your pr up thru 5.5.1 and higher branches


about Atlases, border_size and pyglet.resource.image

per-image border size can't possibly work

pyglet.resource.Loader has only two TextureBin s where to add a new image
the current TextureBin.add implementation implicitly uses the border size provided in the TextureBin instantiation, and does not accept an explicit border_size in the add method

I think theres a design problem that predates the last PR.
I was writing a draft to mayself, and probably to coment in the PR, about what feels bad in the current design. It is late, so I will post the draft as is; it was intended to understand the problem and try to suggest a possible fix. Here we go:
Lets review the actual code that deals with image padding
not only the changes in the PR, all of them.
module atlas
class Allocator: does not know about 'border'

method alloc(width, height): the caller must do the 'border' math

class Atlas:

receives 'border' at construction time, stored at atlas._border
atlas.add(img): does not receive 'border' info;

always applies implicitly atlas._border
returns a texture region

class TextureBin:
- receives 'border' at construction time, stored at bin._border
- bin.add(img): does not receive 'border' info
- if an existing atlas has space, add the image to it, which will use the atlas._border
- if no space, adds a new atlas, with border=bin.border
- returns the texture region returned by the atlas
This tells that:

all images in an atlas will have a border guard with size 'border', the same specified at atlas creation
all images in a bin will have a guard border of 'border' size, where border was specified at TextureBin creation time.
pros: consistence both in the same run and different runs which load in different order or different images (more enemies maybe)
cons: if not all images need padding, or need different paddings, the images will pack a bit less efficiently

module resource
class Loader, methods

__init__:

initializes self._texture_atlas_bins = {}, a container of TextureBin 's used to store image resources

image(name, ..., atlas=True, atlas_border=1)

basically, ignoring the flip_z and rotate params, if img seen before, returns the cached image,	else calls Loader._alloc_image(name, atlas=atlas, atlas_border=atlas_border) to get a texture region that it will cache and return.
It returns a texture not in an atlas or a texture region in one of the TextureBin in self._texture_atlas_bins

_alloc_image(self, name, atlas=True, atlas_border=1)

if not atlas or img size too big to fit in a bin returns a texture not in an atlas; 'border' correctly not applied here
else returns bin.add(img), when bin is the TextureBin returned by
Loader._get_texture_atlas_bin(width, height, atlas_border)
returns a texture not in an atlas or a region into one of the TextureBin in self._texture_atlas_bins

_get_texture_atlas_bin(img.width, img.height, atlas_border)

if the texture size is too big, returns None, else it derives a key from the texture size needed,
if there is a bin for that key, it returns that bin,
else, creates a TextureBin with border= the param 'border' received in the call, adds the bin to available bins and returns the new bin

This tells that:

the promise in Loader.image to allow independent border size cannot posibily hold with this implementation, because they are at most two bins, and bin.add does not accept a border_size param.

each TextureBin in self._texture_atlas_bins gets the border size set by the first image that enters the bin. Very unstable.

Simplify
Start by looking at plausible user cases
fast and simple use case
Be it for new users or experiended users doing a fast prototype, an uniform k-pixel image padding by default will work most of the time. The precise k value may depend on level of zooming.
At this level the user will not want to build a custom loader, so it will not use directly Atlas or TextureBin; only pyglet.resource.image
A member Loader.default_image_padding can hold the k value, which has an initial value=1
This value is allowed to change before the first call to pyglet.resource.image / Loader.image, ReadOnly after that.
Here theres a design decision to be done: allow or not to specify a border_size in Loader.image ?
Lets look at advanced use cases before take a decision
advanced use cases
The purpose is not to build an advanced api, more like explore what probably be its needs so that
design decisions for the easy case dont innecesary limit the advanced cases
It is safe to say there will be a fight between diferent criteria for grouping images, by example

group the ones that will share drawing params (to minimize gl state changes)
group to minimize texture changes while rendering some geometry
group by time-of-life affinity, to minimize fragmentation
this set of images must live in the same texture (for some critical shader)

Whatever the compromise reached, it will end with some image groups, and a loader that will take an image, a hint and based on the hint will assign the image to that group.
I don't see 'desired padding' an important criteria to group images, the other criteria are more significative.
So I would say that Atlas and TextureBin, which expresses some units of grouping, don't need to force an additional 'group by padding'
Hence:

remove the atlas_border param in __init__ and it associated member ._border from Atlas and TextureBin

augment the method add from
	add(self, img)
to
    add(self, image, border_size=0)

Now border_size does not limit grouping by more important criteria in the advanced case.
The small price to pay in the advanced case is that somehow a border_size must be obtained when checkin-in an image; this can be implicitly passed in the hint, or as an explicit separate argument.
It does not impact the simple use case because border_size can be provided by Loader.default_border_size, or, if pyglet.image.loader is allowed to receive a border_size, from there.
Now it is no problem to mix different border_sizes in the bins used by Loader.
Loader.image signature must change from:
	def image(self, name, flip_x=False, flip_y=False, rotate=0, atlas=True, atlas_border=1)
to ( If we allow to pass border_size in the simple use case )
	def image(self, name, flip_x=False, flip_y=False, rotate=0, atlas=True, atlas_border=None)
          #atlas_border None means use atlas_border = Loader.default_image_padding
or (if per-image border_size are not allowed)
	def image(self, name, flip_x=False, flip_y=False, rotate=0, atlas=True)
Recap changes suggested

Atlas and TextureBin does not receive a border param in __init__, not have related member ._border
Atlas and TextureBin change the add method from
add(img)
to
add(img, border_size=0)
class Loader gains a new instance member (property?) 'default_border_size', initialized to 1 that can be changed before the fist call to image is made, then its remains ReadOnly
Loader.image changes in the way show above

Backward compatibilty
Behavior for the simple case is the same as was desired before the PR was done, implicitly use border_size=1
Advanced cases, which directly access Atlas and TextureBin, may need adjustments if they expected some default padding to be provided.
At this time, I bet the principal customer for advanced cases is pyglet itself (fonts, animations, ...), so theres a need to evaluate how hard would be to adjust
Extenal advanced users: if the use cases in pyglet are resolved, a request for coments could be done in the mailing list ?

Thanks for taking the time to write that up Claudio. I realized the issue as soon as I saw your ticket, but I didn't think of it at the time.
I also had the same thought - to add the border argument to the add method. I'll have a look at this today/tonight, and make an update with that first step. We can then look it over again and make sure it looks reasonable before I push out the next release.

I had a quick look, at I think using a default_border class attribute will work well. This is the same technique we currently use for the Texture class, and min/mag filter defaults. Something like this:
class TextureAtlas:

    default_border = 0

    def __init__(self, width=2048, height=2048):
        ....

    def add(self, img, border=None):
        ....
        border = border or self.default_border

This will allow you to set a default border for all TextureAtlases/Bins:
pyglet.image.atlas.TextureAtlas.default_border = 2

Or, set the default for a specific TextureAtlas/Bin after instantiating:
my_atlas = pyglet.image.atlas.TextureAtlas()
my_atlas.default_border = 1

And of course users can provide a border size when calling the add method, to explicitly set the border regardless of what the default might be:
my_atlas.add(img, border=2)

The resource module will probably just pass in the border argument to add, with the the default being 1.
What do you think?

I pushed my changes into the pyglet-1.5-maintenance branch so you can have an easier look.

I think it can work.
Maybe not have a separate default_border in the resource module now that
there is the class default,
On Sat, May 30, 2020 at 5:42 AM Benjamin<EMAIL_ADDRESS>wrote:

I pushed my changes into the pyglet-1.5-maintenance branch so you can
have an easier look.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pyglet/pyglet/issues/217#issuecomment-636300133, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACYN3BWZASNEF5N4U4KZBLRUDBJFANCNFSM4NOSHPWA
.

Looking at the commit diff I spotted some small issues:
** things that I see as bugs
atlas.py

both in Atlas.add and TextureBin.add

in the docsting, looks like

          `border` : int
              Leaves specified pixels of blank space around
              each image added to the Atlas.

should be
          `border` : int or None
              Leaves specified pixels of blank space around
              each image added to the Atlas.
              if None, border = self.default_border is used

and maybe the 'blank space' should change to more explicit wording, like 'fully transparent" or color (0, 0, 0, 0)

the line
border = border or self.default_border
should be
border = self.default_border if border is None else border
(the first version fails when border==0)

resource.py

in Loader

should be

Why have two default_border managements when resource can use the one in atlas ?
It is simpler to understand and modify  only one system

in Loader, method _get_texture_atlas_bin(self, width, height) has a problem in this block
      # Large images are not placed in an atlas
      max_texture_size = pyglet.image.get_max_texture_size()
      max_size = min(2048, max_texture_size)
      if width > max_size or height > max_size:
          return None

It does not cover some corner cases, like
      and (width <= pyglet.image.get_max_texture_size())
      and (max_size == pyglet.image.get_max_texture_size())
      and border >0 )

An image with those conditions will not fit in any TextureBin texture region, because the region size, when including the pading, would be greater than max texture size available from openGL
Yet it would fit in a texture not included in an atlas, because tx_size <= max gl tx size
One tentative way to fix would be to leave this block alone, catch in the code below thar block the exception for 'gl texture request fails because texture too big' and return None in that case.
Other more compicate will be to try something similar to this : add a border=None kwarg, to receive border, and change the block to
      # Large images are not placed in an atlas
      real_border = TextureBin.default_border if border is None else border
      max_texture_size = pyglet.image.get_max_texture_size() - real_border
      max_size = min(2048, max_texture_size)
      if width > max_size or height > max_size:
          return None

I dont like that  TextureBin.default_border ; it would be safer to have a Loader.default_size
Lunch time, I will left here for now

I see in Loader
def image(self, name, flip_x=False, flip_y=False, rotate=0, atlas=True, border=1)

and
def animation(self, name, flip_x=False, flip_y=False, rotate=0, border=1)

It is similar to the line
def _alloc_image(self, name, atlas=True, border=1)

mentioned in the comment above.
Three points in which the default_border set in Atlas and TextureBin are disregarded.
From a higher level point of view

Atlas and TextureBin are containers which can be used from one or more loaders
Each loader may want to use its own default_border
So it is simpler if  default_border is kept in the loader code; in particular for the pyglet default loader, pyglet.resource.Loader. As an instance member, for good mesure.
and then change those ,border=1) to ,border=None)

thats my 2c

In my view:

Atlas and TextureBin are containers which can be used from one or more loaders

While true, if you intend to use atlas and bin's, using separate loaders is actually negative, because you are creating separate atlases which defeats the purpose of them. (Multiple loaders do not share the same atlas bins)

Each loader may want to use its own default_border

I think this removes functionality. I can use or not use a border even with a separate function call with any image. As a class level, I would have to change it before and after every load.

So it is simpler if default_border is kept in the loader code; in particular for the pyglet default loader, pyglet.resource.Loader. As an instance member, for good mesure.

The default loader is also a private module variable, which makes trying to modify a class variable appear improper to a user (example:pyglet.resource._default_loader.atlas_border = 1), not sure it's the best fit or maybe just make it public? Also it is inconsistent in that there is no other class variables for Loaders which users set, which seems out of place.

and then change those ,border=1) to ,border=None)

I think it's important to keep the variable type consistent and 0 should have the same effect as None in this case, as in no border.

On Mon, Jun 1, 2020 at 3:35 PM caffeinepills<EMAIL_ADDRESS>wrote:

In my view:
Atlas and TextureBin are containers which can be used from one or more
loaders
While true, if you intend to use atlas and bin's, using separate loaders
is actually negative, because you are creating separate atlases which
defeats the purpose of them. (Multiple loaders do not share the same atlas
bins)

You want to pack together images with some affinity, and keep separated
from ones with other affinities. Think blend modes, or interpolation modes.
One big TextureBin can be detrimental.

Each loader may want to use its own default_border
I think this removes functionality. I can use or not use a border even
with a separate function call with any image. As a class level, I would
have to change it before and after every load. Otherwise that means I will
no longer be able to load certain images with no border, and some images
with a border in the same loader to the same atlas.

???
class MyLoader:
    def __init__(self, path=None, script_home=None, default_border=0):
        self.default_border = default_border
        ...

     def image(self, name, flip_x=False, flip_y=False, rotate=0,
atlas=True, border=None):
         border = self.default_border if border is None else border
         ...

User code will not need to specify border if it is using the default, nor
change anything before calling image if it wants a different border

So it is simpler if default_border is kept in the loader code; in
particular for the pyglet default loader, pyglet.resource.Loader. As an
instance member, for good mesure.
The default loader is also a private module variable, which makes trying
to modify a class variable appear improper to a user (example:pyglet.resource._default_loader.atlas_border
= 1), not sure it's the best fit or maybe just make it public? Also it is
inconsistent in that there is no other class variables for Loaders which
users set, which seems out of place

I said instance variable, not class.
The 'private' card I can't contest

.
and then change those ,border=1) to ,border=None)
I think it's important to keep the variable type consistent and 0 should
have the same effect as None in this case, as in no border.

In my narration, border=0 means you want border==0, and border=None means
border will be set to default_border
In caller code,
myloader.image(..., border=0): means caller want's exactly 0 border
calling without an explicit border, or border=None, means caller is fine
with wathever default is set, and this meaning will not change if in the
evolution of usercode the default_border es changed.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pyglet/pyglet/issues/217#issuecomment-637033243, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACYN3GMVHKT75SG4QIAKZTRUPYHHANCNFSM4NOSHPWA
.
[image: image.gif]

I just made another push. I cleaned up a lot of the redundant arguments in resource, and fixed the logical error in the _get_texture_bin method (thanks for catching that!).
For this iteration, I removed the default_border attribute for the TextureBin/Atlas classes. I wonder after all the discussion, do we really need it? Allowing users to explicitly request a border size when calling add methods might be enough for the time being.

The latest releases have the explicit border arguments for the add methods. Do you guys think we should take this further, or leave it for the time being?

I'm ok with leave as it is.
Thanks for all your work, cheers

I'll close this for now then, but in the future we can certainly have another discussion about improvements. Thanks for starting the conversation!


Don't define incorrect ssize_t on Windows

Scope & Purpose
Correct ssize_t include looks like
#ifdef _MSC_VER
  #include <BaseTsd.h>
  using ssize_t = SSIZE_T;
#else
  #include <unistd.h>
#endif

Or better don't use ssize_t, because we have ptrdiff_t
Now we use int on Windows, it's incorrect but I don't want to change it.
So just remove using and replace to auto/int/ptrdiff_t

[ ] :hankey: Bugfix
[ ] :pizza: New feature
[ ] :fire: Performance improvement
[ ] :hammer: Refactoring/simplification

Checklist

[ ] Tests

[ ] Regression tests
[ ] C++ Unit tests
[ ] integration tests
[ ] resilience tests

[ ] :book: CHANGELOG entry made
[ ] :books: documentation written (release notes, API changes, ...)
[ ] Backports

[ ] Backport for 3.10: (Please link PR)
[ ] Backport for 3.9: (Please link PR)
[ ] Backport for 3.8: (Please link PR)

Related Information
(Please reference tickets / specification / other PRs etc)

[ ] Docs PR:
[ ] Enterprise PR:
[ ] GitHub issue / Jira ticket:
[ ] Design document:

Would you mind changing the title and the description of the PR to reflect what it does, and why?

Why was this merged? None of our team has approved it yet.
I do not understand why these changes were made in the way they were made.

@markuspf
Sorry, but I don't think we should discuss it here.
Also your team responsible for few files, in which it's just safe replace ssize_t to ptrdiff_t

I do not understand why these changes were made in the way they were made.

What don't you like? Before this changes on windows we use 4 byte ssize_t, it was incorrect.
Also we define our incorrect ssize_t in common header. That doesn't allow us to use library header with correct size_t
Now we use ptrdiff_t/auto.
For nghttp2 created special patch, to make it same way as they did (long instead of ssize_t)


Need github URL updated

Thank you for updating the What is the URL for the project (as a whole)? field in issue #1973.  However, I  need the github URL updated as will.   Getting the same error You may only change your repo_url if it is (1) more than 180 days since it was last changed, or (2) it is only a switch between http and https. Please file an issue (with rationale) if you need to change it sooner.
What is the URL for the version control repository (it may be the same as the project URL)?
https://github.com/sdo-device-onboard -> https://github.com/fido-device-onboard
this if for project https://bestpractices.coreinfrastructure.org/en/projects/6714

I can't change project 6714 (fido device onboard) to use the URL <https://github.com/fido-device-onboard> because that repo URL is already being used by project 7456 (fidodeviceonboard).
Are these duplicate entries? If so, you probably should merge them - tell me which one to remove & I can do that.
Also, these "repo" URLs are really the set of repos for an organization. You can do that, and no ill will befall you. However, a lot of automation won't work because it's expecting a single repo. So if that's the best way to represent what you're doing, then that's great, but make sure that's what you meant to do :-).
The limits on changing repo URLs are there to counter some bad actors, but they may be too strict. Maybe we should relax them a bit. We can probably notice things like "change from https://github.com/FOO to https://github.com/FOO/BAR is always okay", and we could also reduce the change delay time.


Fix search params issue in cookies preventing visibility for direct navigation

We need to show the yellow pins from the previous search on the location details page
we can't put those params in the URL, because of SEO optimization
this means the search params are in the cookie
but if you navigate directly to a location, then you don't necessarily want those params to be applied (edited)
you basically just want them to last for a single session and then get cleared

@jbeard4 hasn't been fixed because I think we have a regression here. after I clear cookies, I only see the location pin; I would want to see all other pins without filters on the map, too.
before cookie cleanup:

after cookie clean up (current situation that is not good IMO)

@jbeard4 hasn't been fixed because I think we have a regression here. after I clear cookies, I only see the location pin; I would want to see all other pins without filters on the map, too. before cookie cleanup:  after cookie clean up (current situation that is not good IMO)

@doobneek1 This is expected behavior. I agree, it's not ideal, but it's the best solution available given the constraints of being unable to put the search information in the URL.

Putting this back in Scoped, and adding wont fix label cos of Jake's comment.
If we can get back to it at some point we can.


Binary content

done correctly

Sorry for the delay. Thank you.
The new version of VerificationTimes, as well as Binary body support, ended up being added as part of a bigger refactor to clean up and simplify code and support some important missing features.
New features include async/await, request body matchers in general (String, XPath, JsonPath, Regex, Binary, etc), response body content in general (Plain Text, XML, JSON and Binary), One-way/Two-way TLS and other API simplifications.
Regarding the change to support .NET Framework 4.6.1, there's currently no plan to do so in this repository, because .netstandard2.0 shall be compatible with both .NET Framework (4.6.1 and later) and .NET Core (2.0 and later).


fix for environments with changes in Object.prototype

Although it's not recommended to, but it's allowed to augment Object.prototype with more properties and methods. Using hasOwnProperty enables Mustache to work with no changes in those environments.

Hi! After a refactor, we now compile partials on demand, so there is no for in loop anymore. I would have merged, but there is no loop anymore, sorry. :/

If it works out-of-the-box, not merging is not a problem xD

Yeah, but you took the effort to make the PR, so it's a shame. :)


Added logging to GitHub commit status publishing

Description
Currently, sometimes there is a problem with GitHub status updates:

http://jenkins.mxnet-ci.amazon-ml.com/job/mxnet-validation/job/windows-gpu/view/change-requests/job/PR-13208/4/console
http://jenkins.mxnet-ci.amazon-ml.com/job/mxnet-validation/job/unix-cpu/view/change-requests/job/PR-13599/3/console

If repoUrl is changed to a not valid url the log shows the exact same error:
[Set GitHub commit status (universal)] SUCCESS on repos [] (sha:90a0bd0) with context:ci/jenkins/mxnet-validation/windows-gpu

Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

The ci/jenkins/mxnet-validation/unix-cpu job succeeded, but status did not propagate.

@lebeg - This is a helpful change. Can we go ahead and merge this?


[Other]: openim-server intermittently unhealthy

What would you like to share?
The openim server component will become unhealthy after a few days, return to normal after restarting, and then become unhealthy again after a few days, repeatedly. At first, I thought there was not enough memory, but increasing the memory to 8GB still couldn't solve the problem. The attachment is a log file from the past month, please review it.
Thanks!
imserverlogs.zip
Additional information
No response

github.com/openimsdk/open-im-server/v3/pkg/common/kafka.(*MConsumerGroup).RegisterHandleAndConsumer(0xc0000a2e00, {0x17309a0, 0xc0000af180})
/openim/openim-server/pkg/common/kafka/consumer_group.go:71 +0x145
created by github.com/openimsdk/open-im-server/v3/internal/msgtransfer.(*MsgTransfer).Start
/openim/openim-server/internal/msgtransfer/init.go:114 +0x1ea
panic: kafka: client has run out of available brokers to talk to
Kafka has crashed, please check the server's memory and disk space, and verify if there are different applications running on it.

It is recommended to update to version 3.5.

The Docker deployment plan has been fully upgraded. Please refer to the README for the new scheme.
The new scheme is simpler to use and supports Linux, Windows, and Mac.


Provide support for SVG extension to load thumbnail.

Please provide support for svg images as the thumbnail fails to load with some of the websites.

This would be very helpful

Hi, This support will be available in V3.0.2

any_link_preview: ^3.0.2 is Live now.
Feel free to open this ticket if the issue persists. Thank you!


Now Secure API uses url params

curl -H "Authorization: Bearer ${API_TOKEN}" -X POST \
    https://lab-api.nowsecure.com/build/?group=838929c6-73c8-11e8-a19d-27d57188d0f9 --data-binary @bin.apk

See: https://docs.nowsecure.com/auto/api/spec/#api-Applications-submitBuild
Need ?group= in script here: https://github.com/sp3nx0r/bitrise-step-nowsecure-auto-analysis/blob/master/step.sh#L8

Woops, stale issue. Closing since PR merged with fix


Unable to create a new LE cert

After updating to the latest version there seems to be a problem with getting LE certs
dockergen.1  | 2015/12/10 16:48:21 Received event start for container d129a08577a5
dockergen.1  | 2015/12/10 16:48:21 Generated '/etc/nginx/conf.d/default.conf' from 2 containers
letsencrypt.1 | Waiting 10s before updating certs...
letsencrypt.1 | Creating/renewal DOMAIN.REMOVED.COM certificates... (DOMAIN.REMOVED.COM)
letsencrypt.1 | 2015-12-10 16:48:31,936:INFO:simp_le:950: Generating new account key
letsencrypt.1 | 2015-12-10 16:48:34,713:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:35,026:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:35,331:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:36,060:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:36,586:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:36,928:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:38,896:INFO:urllib3.connectionpool:188: Starting new HTTP connection (1): DOMAIN.REMOVED.COM
nginx.1      | DOMAIN.REMOVED.COM <IP_ADDRESS> - - [10/Dec/2015:16:48:39 +0000] "GET /.well-known/acme-challenge/WVE_LDs_V2jStfteYzCF-Ym0jvfWXp80BKAnkwH3JhA HTTP/1.1" 503 212 "-" "python-requests/2.4.3 CPython/2.7.9 Linux/3.13.0-30-generic"
letsencrypt.1 | 2015-12-10 16:48:39,040:WARNING:simp_le:1050: DOMAIN.REMOVED.COM was not successfully self-verified. CA is likely to fail as well!
letsencrypt.1 | 2015-12-10 16:48:39,068:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:39,396:INFO:simp_le:1060: Generating new certificate private key
letsencrypt.1 | 2015-12-10 16:48:40,392:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 16:48:40,679:ERROR:simp_le:1018: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Is there a warning log entry about unsuccessful self-verification? Are all your domains accessible from the internet? Failing authorizations: https://acme-v01.api.letsencrypt.org/acme/authz/MDmfx8dik-spcEH_H7YBu8XgSCWBe-syT4vgUMTfpr0
letsencrypt.1 | Challenge validation has failed, see error log.
letsencrypt.1 | Sleep for 3600s
nginx.1      | DOMAIN.REMOVED.COM <IP_ADDRESS> - - [10/Dec/2015:16:48:44 +0000] "GET /.well-known/acme-challenge/WVE_LDs_V2jStfteYzCF-Ym0jvfWXp80BKAnkwH3JhA HTTP/1.1" 503 212 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

As you can see from the log above (with domain removed) it appears to fail before the lets encrypt service does the verification. Could this be some sort of timeout that needs increasing?

I'm not exactly sure why the problem occured. On my test site I deleted the certs from nginx-proxy-letsencrypt container and ran again. I have a www and non-www site, one certificate was issued for both of them. They both work fine when tested in Firefox. Here is my log so you can compare.
forego       | starting nginx.1 on port 5000                                                                                [3/1371]
forego       | starting dockergen.1 on port 5100
forego       | starting letsencrypt.1 on port 5300
letsencrypt.1 | Waiting 10s before updating certs...
dockergen.1  | 2015/12/10 20:32:58 Generated '/etc/nginx/conf.d/default.conf' from 3 containers
dockergen.1  | 2015/12/10 20:32:58 Running '/app/update_nginx'
dockergen.1  | 2015/12/10 20:32:59 Watching docker events
letsencrypt.1 | Creating/renewal letsencrypt.upgradeya.com certificates... (letsencrypt.upgradeya.com www.letsencrypt.upgradeya.com)
letsencrypt.1 | 2015-12-10 20:33:11,569:INFO:simp_le:950: Generating new account key
letsencrypt.1 | 2015-12-10 20:33:15,064:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:15,604:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:15,786:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:16,275:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:19,873:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:20,164:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:20,395:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:20,628:INFO:urllib3.connectionpool:188: Starting new HTTP connection (1): letsencrypt.upgradeya.com
nginx.1      | letsencrypt.upgradeya.com <IP_ADDRESS> - - [10/Dec/2015:20:33:20 +0000] "GET /.well-known/acme-challenge/1404lmpkZbzPsSX9Qq5v4wPpyVrISZGBVZ-OYzmaBLw HTTP/1.1" 200 87 "-" "pytho$-requests/2.4.3 CPython/2.7.9 Linux/4.2.0-18-generic"
letsencrypt.1 | 2015-12-10 20:33:20,737:INFO:simp_le:1052: letsencrypt.upgradeya.com was successfully self-verified
letsencrypt.1 | 2015-12-10 20:33:20,766:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:21,065:INFO:urllib3.connectionpool:188: Starting new HTTP connection (1): www.letsencrypt.upgradeya.com
nginx.1      | www.letsencrypt.upgradeya.com <IP_ADDRESS> - - [10/Dec/2015:20:33:21 +0000] "GET /.well-known/acme-challenge/-tdIYgbhc3G1fQM-R6qiFOwg3KCg48HUXZoIBdBxU88 HTTP/1.1" 200 87 "-" "p$thon-requests/2.4.3 CPython/2.7.9 Linux/4.2.0-18-generic"
letsencrypt.1 | 2015-12-10 20:33:21,158:INFO:simp_le:1052: www.letsencrypt.upgradeya.com was successfully self-verified
letsencrypt.1 | 2015-12-10 20:33:21,258:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
nginx.1      | letsencrypt.upgradeya.com <IP_ADDRESS> - - [10/Dec/2015:20:33:21 +0000] "GET /.well-known/acme-challenge/1404lmpkZbzPsSX9Qq5v4wPpyVrISZGBVZ-OYzmaBLw HTTP/1.1" 200 87 "-" "Mo$illa/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
letsencrypt.1 | 2015-12-10 20:33:21,417:INFO:simp_le:1060: Generating new certificate private key
nginx.1      | www.letsencrypt.upgradeya.com <IP_ADDRESS> - - [10/Dec/2015:20:33:21 +0000] "GET /.well-known/acme-challenge/-tdIYgbhc3G1fQM-R6qiFOwg3KCg48HUXZoIBdBxU88 HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
letsencrypt.1 | 2015-12-10 20:33:27,461:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:27,604:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:27,749:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:27,967:INFO:urllib3.connectionpool:697: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
letsencrypt.1 | 2015-12-10 20:33:28,162:INFO:simp_le:335: Saving account_key.json
letsencrypt.1 | 2015-12-10 20:33:28,163:INFO:simp_le:335: Saving key.pem
letsencrypt.1 | 2015-12-10 20:33:28,164:INFO:simp_le:335: Saving fullchain.pem
letsencrypt.1 | Creating/renewal letsencrypt2.upgradeya.com certificates... (letsencrypt2.upgradeya.com)
letsencrypt.1 | 2015-12-10 20:33:31,179:INFO:simp_le:1117: Certificates already exist and renewal is not necessary, exiting with status code 1.
letsencrypt.1 | 2015/12/10 20:33:31 Generated '/etc/nginx/conf.d/default.conf' from 3 containers
letsencrypt.1 | 2015/12/10 20:33:31 [notice] 58#58: signal process started
letsencrypt.1 | Sleep for 3600s

If it is a timeout issue, perhaps you can run the container again and see if it works. Maybe Let's Encrypt was slow for some reason. I'll look into simp_le waiting a little bit longer for a response. I'm not sure that can be adjusted.

You can also manually force nginx-proxy-letsencrypt to try and update agian with:
docker exec nginx_proxy_letsencrypt_cid ./update_certs

I'm running into the same error message. Tried to recreate the container like suggested but no dice.

Did you set the VIRTUAL_HOST variable? nginx-proxy-letsencrypt will return a 503 error if there is no VIRTUAL_HOST it can find. Both VIRTUAL_HOST and LETSENCRYPT_HOST need to be set.
Maybe compare your setup to the example here: https://github.com/dmp1ce/nginx-proxy-letsencrypt#lets-encrypt

@dmp1ce it looks overnight it tried to get a new cert every hour but ultimately failed every time.
It has previously worked for me in a version I pulled a few days ago, but this latest version doesn't seem to work :(

The line
DOMAIN.REMOVED.COM was not successfully self-verified. CA is likely to fail as well!
is often display when you didn't set VIRTUAL_HOST with the same domain name(s) OR your dns do not point the IP of DOMAIN.REMOVED.COM to the ip of the nginx-proxy server

@adamlc What command are you using to run nginx-proxy-letsencrypt? I would expect it to work if it worked in the past. Not much has changed. Are you able to access DOMAIN.REMOVED.COM with or without TLS? Are you able to access http://DOMAIN.REMOVED.COM/.well-known/acme-challenge/WVE_LDs_V2jStfteYzCF-Ym0jvfWXp80BKAnkwH3JhA? It needs to be accessable for Let's Encrypt to succeed.

hi @dmp1ce. Not had much time to have a look at this, but I recreated the proxy container 3 times, and on the third time it worked fine! So I would guess it could be something to do with LE getting hammered?

@adamlc I'm glad it finally worked! I'll keep this issue open for awhile if anyone else who is having trouble getting certificates.

@dmp1ce Problem is solved for me as well. Working just fine now! Might have been something on LE's end.

I had a similar problem. Sometimes I've noticed a bit of delay with certificate creations, but one time it seemed that no matter how long I waited the registration never happened. The log output was roughly the same. I did ensure that the domains in both VIRTUAL_HOST and LETSENCRYPT_HOST were limited to one domain and that DNS resolved accurately. I was even able to wget the acme-challenge. In the end I just generated the files manually and placed them in the appropriate directories and restarted the container. Everything came up without issue using that method. I think in some cases the CA self-check might be throwing an error when it may actually succeed on the letsencrypt end; perhaps the 503 redirect is misleading it.
Side note: I'm using JrCs's nginx-proxy-letsencrypt-companion.

I have a similar issue and wondered if anyone here could lend a hand: http://stackoverflow.com/questions/43641812/ca-marked-some-of-the-authorizations-as-invalid

I had this issue too.
It seems my new container (the docker registry) used a new network registry_default. I'm not sure why, I'm using docker-compose...
The config in nginx default.conf upstream registry.mydomain.com {} was empty, and /.well-known/acme-challenge request fails then with "503 Service Temporarily Unavailable"
I forced recreated the container, forcing the network to default ("network_mode: default") , and it worked.
There is probably several ways to have this problem...


Fix golint errors in docker/api/client

This commit fixes remaining golint issues in the api/client package, mostly around docs for exported methods and types.
WalkTree and ErrConnectionRefused look like they don't need to be exported since they're only used in their respective packages (I checked Github and sourcegraph.com for potential usages across other repos), and WalkTree is deprecated anyway.

ah awesome!!!

LGTM

LGTM


[UI]: Add a new Catalog page and it's menu item

Notes for Reviewers
This PR fixes #10822

Since, most of the page code is reused from designs page, there is still much refactoring left.

Refactoring Ideas:

use api/pattern/catalog opposed to current api/pattern.
use rtk-query for dataFetch(with endpoints).
use sistent rjsf Schemas.

Prototype page demo:
https://github.com/meshery/meshery/assets/80959679/9507f783-a06c-417d-8acd-f090128f138d
Signed commits

[x] Yes, I signed my commits.

please try to use rtk instead datafetch if you would @dottharun  // @aabidsofi19

@dottharun ready for final review? This is still marked as draft. What's left to complete?
@aabidsofi19

@dottharun ready for final review? This is still marked as draft. What's left to complete?

The CatalogIcon is being added by someone else to sistent, If we are okay with the current one we can proceed to review.

@dottharun still draft?

@dottharun still draft?
Waiting for sistent/641

Testing

@dottharun please disable the "save" button in info modal if used in catalog, it allows to change published designs catalog data.

Also please ensure this is read-only, currently, it allows me to edit published designs and save it.

Also please ensure this is read-only, currently, it allows me to edit published designs and save it.

We'll want to chat through a couple of these scenarios. 👍


The 'effect' of the 'permission' is not taking effect after being set.

#2092
The problem has still not been resolved.

When specific "Sub roles" are configured in "permissions" and "Sub users" is left empty, the "v3" field will still not write "allow" or "deny".

When specific "Sub users" are configured in "permissions", the "v3" field will be written, but the "Allow" and "Deny" written in the field will be capitalized and will not take effect. Only when I change the first letter to lowercase "allow" or "deny" will it take effect.

Version:  v1.367.0
@hsluoyz

2. Only when I change the first letter to lowercase "allow" or "deny" will it take effect.

Could you post your casbin model? Theoretically speaking, the action in the policy is the same as in the model.

Only when I change the first letter to lowercase "allow" or "deny" will it take effect.

Could you post your casbin model? Theoretically speaking, the eft in the policy is the same as in the model.
@imp2002

Model text:
[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act, eft

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

If I try to change 'allow' to 'Allow' in p.eft == allow, it will result in an error message stating 'unsupported effect'.

can try use allow? Maybe the implementation of eft needs to be improved, waiting for discussion.

can try use allow? Maybe the implementation of eft needs to be improved, waiting for discussion.

'allow' is not the issue. The problem I encountered is with the incorrect database operation on the Casdoor web page.


✨Table to show resources that reference a given ID

Closes #18
Click on a row from the details table will produce an additional table that shows which resources reference the given ID.

Hm so what is the behavior if there is more than one of that type referencing the Patient?

In your example, you had 1 Biosample referencing Patient. I just meant that instead of showing all possible Biospecimens, you should show the ones (however many there are) that reference the Patient instance.

I'm wondering if it makes more sense to show the payloads of the reference resources? I guess my question is, is it a use case that a user would want to see just a snapshot of the  resource references? or do they just want to know the IDs? this kind of gets into filtering resources/cohorts building/etc and I just want to make sure that it fits in with our goal for this dashboard, if that makes sense.
Could also show the IDs and then clicking on an ID shows the payload?

Could also show the IDs and then clicking on an ID shows the payload?

👍


A new type for data that should never be logged.

Cargo occasionally deals with secrets. We should have a new type that does not implement Display that is used in the type system to mark "this value is secret and should not be printed". Types that should be converted are plaintext tokens and PASETO after they've been generated.
cc:

https://github.com/rust-lang/cargo/pull/10771#issuecomment-1347580139
https://github.com/rust-lang/cargo/issues/10519

@rustbot claim


istio-proxy sds  failed to warn certificate x509: certficate signed by unknown authority

Bug Description
environment：
cluster 1 ---> external cluster
cluster 2 ---> remote cluster
in single net
cluster 1 istiod in ns external-istiod
cluster 2 deployed sleep app in ns sample
they all mount the same  root-ca.pem produced by the script,
cacert secret are mounted by two cluster, kube-apiserver
injection works well:
cluster 2 (kube-apiserver(injection))--->cluster 1 svc(nodePort) ---> cluster 1 istiod
the sleep app in cluster 2 is inject correctly by cluster 1.
[root@master0 ~]# kubectl -n sample get po
NAME                             READY   STATUS    RESTARTS   AGE
helloworld-v1-776f57d5f6-cr98b   1/2     Running   0          42h
sleep-557747455f-fchqr           1/2     Running   0          43m

but as shown above, the sidecar istio-proxy cannot running, no matter if i disabled the PeerAuthentication in ns external-istiod(cluster1, cluster2)
istio-proxy logs

Version
[root@w istio-remote]# istioctl version
client version: 1.12.6
control plane version: 1.11.3
data plane version: 1.11.3 (1 proxies)
[root@w istio-remote]# kubectl version --short --context=local(external-cluster)
Client Version: v1.19.8
Server Version: v1.19.8
[root@w istio-remote]# kubectl version --short --context=k8s-17-77(remote cluster)
Client Version: v1.19.8
Server Version: v1.19.8

Additional Information
No response

@lei-tang @shankgan Could you take a look?

Which installation guide did you use to install and configure your mesh?

install guide
cert generate guide
step 1: generate certs based on [cert generate guide]
certs/
├── cluster1
│   ├── ca-cert.pem
│   ├── ca-key.pem
│   ├── cert-chain.pem
│   └── root-cert.pem
├── cluster2
│   ├── ca-cert.pem
│   ├── ca-key.pem
│   ├── cert-chain.pem
│   └── root-cert.pem
├── makefile # is istio official makefile
│   ├── common.mk
│   ├── Makefile.k8s.mk
│   └── Makefile.selfsigned.mk
├── mtls.yaml
├── root-ca.conf
├── root-cert.csr
├── root-cert.pem
├── root-cert.srl
└── root-key.pem

step 2: mount certs/cluster1 cert for both remote-cluster and external-cluster, make sure it trust by all kube-apiserver( that's why sidecar injection succeed).
no matter if i mount cluster 2/**pem   or cluster1/**pem to remote-cluster actually, so just mount the same certs  cluster1/**pem in both cluster for simplifies.
kubectl --context=${EXTERNAL_CLUSTER_CONTEXT} create secret generic cacerts -n external-istiod --from-file=certs/cluster1/ca-cert.pem --from-file=certs/cluster1/ca-key.pem --from-file=certs/cluster1/root-cert.pem --from-file=certs/cluster1/cert-chain.pem

# create ns  sample  for test first
kubectl --context=${REMOTE_CLUSTER_CONTEXT} create secret generic cacerts -n sample--from-file=certs/cluster1/ca-cert.pem --from-file=certs/cluster1/ca-key.pem --from-file=certs/cluster1/root-cert.pem --from-file=certs/cluster1/cert-chain.pem

step 3:  follow the picture( in the install guide), but i skipped create gw, dr, vs to expose istiod in external-cluster, but expose istiod by change the  svc istiod to NodePort. btw, u should make the mutatingwebhookconfigurations  is right in both cluster, so sidecar inject succeed in remote-cluster by external-cluster.
service:
  ports:
  - name: status-port
    nodePort: 31021
    port: 15021
    targetPort: 15021
  - name: tls-xds
    nodePort: 31012
    port: 15012
    targetPort: 15012
  - name: tls-webhook
    nodePort: 31017
    port: 15017
    targetPort: 15017
  type: NodePort

the error log in istio-proxy seems reported by https://github.com/istio/istio/blob/125f7ab997982bb0306c57f7858a855223e9abb1/security/pkg/nodeagent/caclient/providers/citadel/client.go#L108

For diagnosis purpose, if you only follow the install guide, will the problem occur?

yes, and the sidecar will not be inject.

Thanks for the clarification! When you only follow the install guide, at which step do you encounter the problem?
cc @frankbu

thx for your patience, @lei-tang @yhuanghamu
would you take a look on this?   @frankbu
when  i deploy an sample app in remote-cluster,  the remote-cluster kube-apiserver cannot connect to the istiod which in external-cluster

i've tried the guide, failed too. compared the arch with the install guide shown above, it's so similar, but according https://github.com/istio/istio/issues/27420, it's still unresolved, is
anything i missed?
test on the original cluster showed in Version


task (INT-1066): Datetime 24/12 feature + Styles updates

Pull request type
Jira Link: INT-1066

[x] Feature

How to test this PR
Access the preview and see the changes in the time component, now it is possible to see the time in AM/PM format and it is also possible to change the timezone
Link for the design
https://github.com/storyblok/storyblok-design-system/assets/40925579/7a20753e-d58b-401c-b40a-f24314def72a
What is the new behavior?

Styles
Possiblity to change the timezone
AM/PM format

Other information

@ademarCardoso I think it didn't run the unit tests because it's going to a story branch. I'll check the config

We need to cross check this PR with the actual app since it's so big

This PR has a lot of changes because of this file for the timezones

@lisilinhart I refactor all tests for this new DatepickerTime updates

Great work Ademar :) maybe we should have a QA check in the storybook too or on a PR in the app

Yes, Carlos will test this scenarios


vote for Governance update

The governance has been revised on August 4, 2022. All the TSC maintainers are invited to vote on the update of the technical charter and the governance: agree vs. disagree. Please complete your vote by 23:59 pm on 7 August 2022（GMT+8）.
The document will become effective when 2/3 of TSC members vote for approval.

agree

agree

aggree

agree

agree

agree

agree

agree

agree

LGTM

agree

agree

agree

agree

agree

Approved unanimously.
This revised version of the governance is effective from August 8, 2022.

agree


Close window instead of killing it

Hi, new user here. I noticed that sowm kills windows instead of closing them. It wouldn't be that big of a deal if Firefox didn't try to restore session every time I open it.
I did found this issue: https://github.com/dylanaraps/sowm/pull/60. And I see that it has been merged with master but, it isn't (??)
https://github.com/dylanaraps/sowm/blob/95596f43aac5f191d96f51290981e860f45eaa55/sowm.c#L124-L126
I tried to patch it with the diff in the mentioned issue, but after that I couldn't close windows at all...

Yes. The commit for #60 broke things. This is the behavior I personally desire which is why sowm works this way. A patch can be written for normal close. Thanks for opening this issue.

The patch breaks closing windows because of how the XEvent is passed.
while writing my own window manager. i tried to send the close event like it is in the diff. didnt work for me.
so i explicitly created a XEvent variable and set the required fields. like so.
 void win_kill(const Arg arg) {
    if (!cur) return;
    XEvent ev;
    ev.type                 = ClientMessage,
    ev.xclient.window       = cur->w,
    ev.xclient.message_type = XInternAtom(d, "WM_PROTOCOLS", True),
    ev.xclient.format       = 32,
    ev.xclient.data.l[0]    = XInternAtom(d, "WM_DELETE_WINDOW", True),
    ev.xclient.data.l[1]    = CurrentTime

    XSendEvent(d, cur->w, False, NoEventMask, &ev);
 }

Note: Closing windows this way will only work if the window supports the DELETE Protocol. for example Xephyr does not support the DELETE Protocol. the only way a window manager can Close(or kill in this case) is by calling XKillClient.

@Abh15h3k Thank you! This works perfectly! I was originally going to borrow some code from spectrwm or bspwm, but I'm not a C programmer so, it could have been interesting to say the least.
I'm not that much worried about the DELETE protocol, I really only use urxvt and Firefox and both work fine
(Also the compiler was complaining about missing ; before XSendEvent so I added one after the CurrentTime)

(Also the compiler was complaining about missing ; before XSendEvent so I added one after the CurrentTime)

whoops. must've copied the wrong thing. they should all end with ;

Maybe make your own diff?

i don't know if i should include the "fix" for windows that don't close with this method. cause that would make the diff rather big. which feels like going against what i see in this window manager. clean, simple, small

whoops. must've copied the wrong thing. they should all end with ;

Ah, thanks ok I did have that feeling

i don't know if i should include the "fix" for windows that don't close with this method. cause that would make the diff rather big. which feels like going against what i see in this window manager. clean, simple, small

I mean this is enough (at least for me). It's still a optional patch, so I wouldn't worry about it not working for everything too much, just point it out.


Switch to setup-beam github action

changes ci.yml to use setup-beam for all tests, except 19 which is still an ongoing issue with setup-beam

We will wait until monday to merge so we can set the version in our config to @v1

We should go ahead and merge this, we can simply do another PR to change to @v1 when its done.


sepolia controller address fetching and codegen

Summary by CodeRabbit
Release Notes

New Features

Introduced a debounced input mechanism for address validation in the Transfer Season Pass dialog, enhancing user experience by reducing immediate validation calls.
Added a "Select/Deselect All Realms" button in the UI for improved interaction.

Bug Fixes

Streamlined error handling for address validation, providing clearer messages for invalid input.

Improvements

Updated variable names for consistency across components, ensuring clarity in the use of user addresses.

just pushed prettier but lgtm


[Feature-WIP][Connector-V2][Doris] Add Doris ConnectorV2 Source

Purpose of this pull request

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

Please fix code style. you can use  sh tools/spotless_check/pre-commit.sh

Please fix code style. you can use  sh tools/spotless_check/pre-commit.sh

Done

org.apache.seatunnel.e2e.connector.doris.DorisIT.testDoris has failed. It needs to be addressed.

pls check you docs styke

why this commit not be merged?  when doris source can be integration? thks.

why this commit not be merged? when doris source can be integration? thks.

Hi @dzygoon , this pr is working in process. After it ready, we can start review it. Then merge it.

why this commit not be merged? when doris source can be integration? thks.

Hi @dzygoon , this pr is working in process. After it ready, we can start review it. Then merge it.

Okay.

Hi, @bingquanzhao This pr is duplicated with  https://github.com/apache/seatunnel/pull/6161. I will close this pr.
Thanks from your contribution.


Increase upperbound on haskell tls package

Vaultenv is currently marked as broken in nixpkgs (24.05) because of the haskell dependency constraint : tls >=1.4 && <1.7
Would it be possible to release a new version that supports tls 1.8, the current latest version used in nixpkgs 24.05 ?
Thanks

@PierreR I just released v0.17.0 which uses tls-1.8.0 when I build it in the nix environment of this repository.


Autotests: #3149 Attachment Point Tool

How the feature works? / How did you fix the issue?
(Screenshots, videos, or GIFs, if applicable)
Check list

[ ] unit-tests written
[x] e2e-tests written
[x] documentation updated
[x] PR name follows the pattern #1234 – issue name
[x] branch name doesn't contain '#'
[x] PR is linked with the issue
[ ] base branch (master or release/xx) is correct
[x] task status changed to "Code review"


[Feature] Shareable links to recreate precise views

It would be a super convenient feature to be able to generate a 'share' link that regenerates a view environment I've created on a particular S3 asset
Right now the workflow is to share the link to the file, together with instructions of what neurodata types to click on, and what range to view them over, possibly with a snapshot of what I'm personally looking at
But if someone could just follow the URL and it automatically creates the view, it could make it super easy for people to collaborate on a discovery during data exploration

Thanks for the suggestion, I agree this would be super helpful.
The strategy that comes to mind is to embed the full state in the URL. However, if the state is complex (many tabs open, navigated to particular timepoints, etc.), this could end up making the url inconveniently long. An alternative is to persist the state in some database, which adds quite a bit of complexity to the app. Maybe the best way forward is to allow sharing a limited state, like a single tab.

Another issue to consider is the possibility that the app might change in a way that breaks old links, which is annoying.

I agree this would be very valuable. Persisting the state in a database is an interesting idea but I think I prefer the url. It does not rely on a database being maintained and it can be created so that it is transparent to the user what information is being passed.
As for long urls, you could do what Youtube does and offer the option of sharing the state (in their case just starting time of the video) or just the video link without any state.

We could similarly have a "share" link, which would allow you to include state variables.
I guess in either case you would need to have each view class expose its full parameterization.
To get around the breaking issue, we could also pass the version of neurosift and keep around old major versions, though I don't think that's necessary yet while we are still getting our feet on the ground.

@magland Looking great, was already super convenient for pointing you to the example tab in #89

@magland Should I open a separate issue for tracking progress on sharing timestamped points in a series?

@CodyCBakerPhD Oops, I closed prematurely. Reopening.

@CodyCBakerPhD
You can now save the selected time range and the current selected timepoint by checking the box when generating the shared URL, as in the following screenshot

And here's an example link
https://flatironinstitute.github.io/neurosift/?p=/nwb&url=https://dandiarchive.s3.amazonaws.com/blobs/544/745/5447455e-49ec-4ce0-9a64-4cad767bef7b&tab=neurodata-item:/processing/behavior/BehavioralTimeSeries/running_speed|TimeSeries&tab-time=90.90120528435017,98.9216642035915,92.86312435285117
(notice the tab-time query parameter)

Closing, as this seems to be working.


Close file after reading

Fixes #139. Tested the repro and did not see a resource warning.

Thanks a lot, @jesseagreene !


Update sociallogins.rst

Added note to install the Microsoft.AspNet.Authentication.Facebook package as it's not installed by default.

Hi @robertjf, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

Merged. Thanks! 122a11f61962fd2188f95b0499c58338b816e358


Added save button to account page

when we go there by click on user onn right upper corner

Nice catch!


Unifi 7.5.174 / MongoDB 4.4 error

I am getting the following error after upgrading to the new Unifi 7.5.174 which includes support for MongoDB 4.4
metric fetch for InfluxDB failed: unifi.GetClients(https://<IP_ADDRESS>:8443): json: cannot unmarshal number 51.47854823087004 into Go struct field Client.data.bytes-r of type int64

OOPS looks like I missed the move to the new package host, been running 2.1.x wow. sorry.


Bluetooth: Mesh: Refactor Config Client and Health Client API to allow async use

Don't ignore unsolicited status messages to allow async use in Health Client and Config Client
Split Unacknowledged API in Health Client
Add more callbacks in Health Client to notify applications of status messages

This PR gives me an idea:
At present, All mesh messages requiring ack are processed synchronously through block k_sem_take.
Can all be changed to asynchronous mode and called through callback.
Is this more flexible for application layer development?

Can all be changed to asynchronous mode and called through callback.

After careful consideration:
This method needs to define all mesh config client status callbacks & health client status callbacks (but it is still const. For some messages that are not planned to be used, the application layer can of course be assigned NULL, although it still wastes 4 bytes of ROM space),
Another problem is that we have defined all cfg_cli status processing functions at present. Even if we do not intend to use them, it still exists. Therefore, it can be changed to a general field analysis function, which can be called by the upper layer at the application layer through callback. We do not use some status processing logic, so it will be optimized away.
For the application layer, it is completely possible to choose asynchronous or synchronous processing, which has more freedom than the current point of view.

@LingaoM I'm not sure I fully understand your proposal, so let me rephrase it:
Instead of having Status processing functions in cfg_cli.c we notify the application that a status message is received and pass raw data and a callback that will process the status message and the application will decide whether it wants to process it?

@LingaoM I'm not sure I fully understand your proposal, so let me rephrase it:
Instead of having Status processing functions in cfg_cli.c we notify the application that a status message is received and pass raw data and a callback that will process the status message and the application will decide whether it wants to process it?

Sure.

unable to get provisioning sample to function, fails to retrieve node composition data _(Failed to get Composition data (err 0, status: 241)_
Was working prior to this change.
Billy..
continuing to investigate


Make a new release

I just started using this action but it never posts a comment, even when there is output in the diff (because the exit code is 0). I think the issue is that the README is newer than the most recent release so the code that runs in the action doesn't match the posted docs.  I think this suggests that the saved exit code is null https://github.com/massgov/openmass/runs/5887414952?check_suite_focus=true

@weitzman did you try running it with strict: true? If I recall correctly, the action will only report the exit code when this parameter is set.

This has been fixed in master branch.


Connection refused appli mobile

Hi,
I haven't been able to connect to rocket.chat mobile applications for a few days now.
Rocket.chat is installed with Docker with Plesk
Rocket.Chat Version: 0.74.3
NodeJS Version: 8.11.4 - x64
Platform: linux
Process Port: 3000
Site URL: https://chat.adcevents.fr
ReplicaSet OpLog: Disabled
Do you have any ideas?
Thank you.

I think this has been fixed - I spent some time with Alexey on open.rocket.chat and we found he had a nginx server he didn't know existed, and it wasn't setup for reverse proxy.
Seems to be OK now.
@alexeyzhuchkov can close this off if he is happy.

YES. Thanks very much @reetp @geekgonecrazy .

And I'm not able to close the issue, as I'm not the originator of that one.

Thanks guys!

9/10 that’s what the issue is.  Just have to walk through the steps to ensure that is the case. Glad you got it


secret environment variables passed through in ci/cd pipeline

extend docs to include instructions on how to configure secret env vars in automated deployment

Thanks!

@swiffer I just realized that the code example actually replaces all the existing environment variables.
Additionally I'm not sure it's a good idea at all because it is not an atomic deployment: first cloudformation will deploy the function and then (seconds later) it defines the environment variables. For a short period the variables will not exist.
Until we document a proper solution (see #7) I think it's best to revert this bit because it will create confusion and frustration for users. Sorry for not catching that sooner!


Move JoinType and JoinCondition to datafusion_common

Which issue does this PR close?
Part of https://github.com/apache/arrow-datafusion/issues/1754 (see https://github.com/apache/arrow-datafusion/issues/1754#issuecomment-1579410979)
Rationale for this change
I am trying to extract physical_plan into its own crate to improve modularity and compile times
JoinType and related structures to are used in physical_plan and I would like to avoid physical_plan depending on the logical plans
What changes are included in this PR?

Move JoinType and JoinCondition to   datafusion_common
Update use paths

Are these changes tested?
Existing tests
Are there any user-facing changes?
No, I left a backwards compatible pub use

Thank you for the review @Dandandan !


Is there a way to sideload an Outlook add-in for IOS devices?

I am developing an add-in for Outlook and would like for it to be available on the iOS Outlook App. In order to do this, I need to be able to sideload and debug my application on an iOS device. I haven't been able to find any documentation on how to do this, specifically for the Outlook application. Is it possible to do?

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

ID: 70e6c303-4a9f-4d68-eb9a-b47d61190a25
Version Independent ID: 42936d64-c5cd-4999-e348-3a0304f8a6e8
Content: Sideload Outlook Add-ins for testing
Content Source: docs/add-ins/sideload-outlook-add-ins-for-testing.md
Product: outlook
GitHub Login: @jasonjoh
Microsoft Alias: jasonjoh

If you side load for OWA then it will be pulled down to your device where you can test it.  You'll need to be sure they are designed for mobile though (https://docs.microsoft.com/en-us/outlook/add-ins/outlook-mobile-addins) since if they aren't, they just won't show up (in particular it needs to support the MobileFormFactor).

I'm going to go ahead and close this since we haven't heard back. If you still need assistance please post details on Stack Overflow.


Add way directly deploy a maven artifact

The artifact is downloaded during the deploy.

FileArtifact was weird because we don't want to grab the artifact during configuration. I can definitely add it to artifactExtension though.

FileArtifact doesn't need to grab the file during config, see here, the same theory applies for FileArtifact https://github.com/JacisNonsense/EmbeddedTools/blob/master/src/main/groovy/jaci/gradle/deploy/artifact/BinaryLibraryArtifact.groovy#L20

Ok, Fixed


it says its a virus

when i start the program my windows defender says there is a virus in my pc from the program as the name: defenseevasion.a ml

there is virus in last version

there is virus in last version

but i dont think theres a virus

Disable your antivirus or add the injector to the exclusion in your antivirus.


Fixing DMs guest label behavior

Summary
The DMs where showing the guest label in any case where a DM has any guest, so
if you are the guest it was showing that for all the DMs, now only show you the
warning when the other user is a guest.
Ticket Link
MM-18939
Checklist

[x] Added or updated unit tests (required for all new features)

Device Information
This PR was tested on: [One Plus 5, Android 9]

@jespino
Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Fetching origin
+++ Updating remotes done...
+++ Creating local branch automated-cherry-pick-of-#3383-upstream-release-1.24-1570614334
Branch 'automated-cherry-pick-of-#3383-upstream-release-1.24-1570614334' set up to track remote branch 'release-1.24' from 'upstream'.
+++ Downloading patch to /tmp/3383.patch (in case you need to do this again)

+++ About to attempt cherry pick of PR. To reattempt:
  $ git am -3 /tmp/3383.patch

Applying: Fixing DMs guest label behavior
Applying: Adding tests
Using index info to reconstruct a base tree...
M	app/screens/channel/channel_nav_bar/channel_title/__snapshots__/channel_title.test.js.snap
A	app/screens/channel_info/__snapshots__/channel_info.test.js.snap
A	app/screens/channel_info/channel_info.test.js
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): app/screens/channel_info/channel_info.test.js deleted in HEAD and modified in Adding tests. Version Adding tests of app/screens/channel_info/channel_info.test.js left in tree.
CONFLICT (modify/delete): app/screens/channel_info/__snapshots__/channel_info.test.js.snap deleted in HEAD and modified in Adding tests. Version Adding tests of app/screens/channel_info/__snapshots__/channel_info.test.js.snap left in tree.
Auto-merging app/screens/channel/channel_nav_bar/channel_title/__snapshots__/channel_title.test.js.snap
Patch failed at 0002 Adding tests
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

+++ Conflicts detected:

!!! None. Did you git am --continue?

+++ Aborting in-progress git am.

+++ Returning you to the master branch and cleaning up.