Extend and refactor template test

What this PR does / why we need it:
This PR adds the following functionality:

[x] Refactor and extend tests.RunCommand() function to be more verbose, to allow separate handling of stdout and stderr, and to confine the executed external command to clearly defined namespace.
[x] Implement new function test.RunCommandPipe() function that allows executing a set of commands chained by stdout pipe. It follows the logic of the new tests.RunCommand().
[x] Extend and refactor tests/template_test.go, simplify code structure and add more test case to comply actual test plan, optimize test time, add the proper annotation to all Gomega matcher calls to simplify debugging.

We need to this PR to optimize test execution and to extend test coverage. This PR also sets the ground for future test automation. The Template test was also modified to be backward compatible with the older KubeVirt releases; thus it is recommendable to include this test into cherry-picked backports.
Special notes for your reviewer:
I provide a detailed description of the partial contributions in the corresponding commit messages. All commits were rebased on top of master branch.
Release note:
NONE

@cynepco3hahue I got your point, and I will most likely refactor the RunCommandPipeWithNS() function within the scope a consequent PR. Thank you for your suggestion.


Prometheus: Support Remote_Write for metrics

For scenarios where external scraping is not possible, it would be neat to support prometheus remote_write feature in addition to the existing scraping.
With remote write applications push their metrics instead of being pulled - would it be possible to implement it for future releases?
Documentation: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write
Older go library for pushing metrics: https://github.com/m3dbx/prometheus_remote_client_golang

Hey @shakalandy!
As far as I understand, remote write is not used for this. I guess Pushgateway is what you're looking for. Yet it has its downsides, and I'd recommend using an OpenTelemetry collector with Prometheus exporter instead.

Ok thanks @DarthSim - we wanted to tackle a use-case, where we can't extend the provided docker-image, and also can't scrape the existing metrics.
We'll have to look for other solutions than.
Thanks for your help, closing this one.


[next-sass] Fail to refer styles using import

Hi guys,
I follow the README to get into sass within an empty NextJS application.
Using require to get styles works, while import fails the compile as below:
Cannot find module './styles.scss'

Did I miss something?
The README is quite clear, though.

I was stuck in the same issue, I solved it with this solution.
Try add typings folder in the directory where pages is.
Make declarations.d.ts in typings.
declare module "*.scss" {
  const content: { [className: string]: string };
  export = content;
}

See issue#91

Hi, thanks for creating an issue. We currently recommend using https://nextjs.org/docs/basic-features/built-in-css-support as the plugins have been deprecated in favor of the built-in support.


nixos/phosh: add Phosh, the Phone Shell

Motivation for this change
Add a desktop-manager for Phosh, to allow easy Phosh setup on Linux phones such as the Pinephone:
services.xserver.desktopManager.phosh = {
  enable = true;
  user = "tom";
  group = "users";
};

This will make a Phosh demo in mobile-nixos easier: best version so far https://github.com/NixOS/mobile-nixos/pull/352.
It's common for Phosh to not run via a display-manager, so that when the phone boots Phosh is immediately running, which has the ability to accept a call.
I'm using this on my Pinephone and can confirm it logs into Phosh on boot.
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

We should consider merging programs.phosh into this to reduce possible confusion.

I applied this to my pinephone config (https://github.com/Mindavi/pinephone-nixos-config/commit/effa803dac297c98c1ac22ff52c7366abd5d1ab3) and rebuilt. It works fine for me.
Also running with the 5.17-rc7 kernel for now.


Disable ReShade in the editor and project manager (if run via Vulkan)

ReShade can still be used on projects run from the editor as well as exported projects.
This avoids several issues:

ReShade doesn't play well with low-processor mode, making it hard to use unless the Update Continuously editor setting is enabled.
The ReShade overlay appears on every popup opened, which made popups unusable.
If you use a ReShade configuration that heavily affects the image, it won't affect the editor UI which may become unreadable as a result.

This doesn't affect the editor being run via OpenGL or Direct3D 12 as ReShade is injected in a different manner when using those graphics APIs.

This closes https://github.com/godotengine/godot/issues/70849.

Preview
Before this PR, this could happen if ReShade was installed for the Godot editor:

With this PR, you can still run ReShade on projects run from the editor - it just won't apply to the editor itself:

Thanks!

Cherry-picked for 4.2.2.


source control view closes

Issue Type: Bug
click on another view and source control view closes.  i keep having to re-open this view.  it is the only view currently doing this behvaior.
system win 10
VS Code version: Code 1.69.2 (3b889b090b5ad5793f524b5d1d39fda662b96a2a, 2022-07-18T16:12:52.460Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No
Extensions (19)

Extension
Author (truncated)
Version

atlascode
atl
2.10.12

path-intellisense
chr
2.8.1

gitlens
eam
12.1.2

svn-scm
joh
2.15.5

vscode-spring-boot
Piv
1.36.0

material-icon-theme
PKi
4.19.0

vscode-jsp
pth
0.0.3

fabric8-analytics
red
0.3.6

java
red
1.8.0

vscode-xml
red
0.21.2022062916

vscode-yaml
red
1.9.1

vscode-checkstyle
she
1.4.1

vscodeintellicode
Vis
1.2.22

vscode-java-debug
vsc
0.42.0

vscode-java-dependency
vsc
0.20.0

vscode-java-pack
vsc
0.24.0

vscode-java-test
vsc
0.35.2

vscode-maven
vsc
0.36.0

easypathconverter
Yuk
1.2.1

(2 theme extensions excluded)

@jessewriter, could you please share a recording (https://gifcap.dev) so that I better understand the behaviour that you are describing.

see how source view keeps disappearing for no reason.

solved.  i must have right clicked in the left hand gutter and unchecked 'source control'

user error :/


Add Torrent Day Provider

Hi, can you add this provider?
https://www.torrentday.com

Invite needed to get access there.

yep, although it is the biggest private tracker nowdays, better than tl.
can arrange you a invite.

@elgatito the login page has google captcha (I'm not a robot), is there a way to do the login?
other than that, this is the configuration:
{
    "torrentday": {
        "enabled": true,
        "predefined": false,
        "private": true,
        "name": "TD",
        "languages": "en",
        "anime_extra": "",
        "anime_keywords": "{title:original} {episode}",
        "anime_query": "/t?29&q=",
        "base_url": "https://www.torrentday.com",
        "color": "FF076700",
        "general_extra": "",
        "general_keywords": "{title:original}",
        "general_query": "",
        "language": null,
        "login_failed": "Invalid username or password",
        "login_object": "{'username': USERNAME, 'password': PASSWORD}",
        "login_path": "/login.php",
        "movie_extra": "",
        "movie_keywords": "{title:original} {year}",
        "movie_query": "/t?-9&q=",
        "parser": {
            "infohash": "",
            "name": "item(tag='a', order=2)",
            "peers": "item(tag='td', order=8)",
            "row": "find_once('table', ('id', 'torrentTable')).find_all('tr')",
            "seeds": "item(tag='td', order=7)",
            "size": "item(tag='td', order=6)",
            "torrent": "item(tag='a', attribute='href', order=3)"
        },
        "season_extra": "",
        "season_extra2": "",
        "season_keywords": "{title:original} season {season:2}",
        "season_keywords2": "{title:original} s{season:2}",
        "season_query": "/t?-8?q=",
        "separator": "+",
        "show_query": "/t?-8?q=",
        "subpage": false,
        "tv_extra": "",
        "tv_extra2": "",
        "tv_keywords": "{title:original} s{season:2}e{episode:2}",
        "tv_keywords2": ""
    }
}

the login page has google captcha (I'm not a robot), is there a way to do the login?

Don't know if there is any way to skip the captcha.

Jackett does it:
https://github.com/Jackett/Jackett/blob/master/src/Jackett.Common/Indexers/TorrentDay.cs

@alonronin great. Then just use Jackett. From Burst it's not possible.


fix: fix debugger logs for performance

Description
This Change includes two parts,

In Debugger Saga, Action is being triggered in a loop, that action is in turn updating Redux State in a loop, This is bad for performance as they end up notifying the all the subscribers of the state. Changed it to update state once rather than doing it individually.
In the Reducer, changed it to ImmerReducer so that only particular object of the local state changes on update rather than updating reference of the entire state.

Fixes #16489
Type of change
performance fix
How Has This Been Tested?
Visual improvement in performance and performance indicators in DevTools
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=b11512a

/ok-to-test sha=b11512a

/ok-to-test sha=8c90a57

@rahulramesha when is this expected to merge in?


Caching in GitHub Actions doesn't seem to be working right

Describe the bug
The GitHub Actions workflows for Nosey Parker don't seem to make effective use of the Actions cache. This causes workflows to run much slower than they might otherwise.
To Reproduce
For example, take a successful CI run, and then rerun it. Examine the details of the actions log. Additionally, check the build timing artifacts that are produced by the CI jobs; these give more details as to how many dependencies are being rebuilt by cargo and how long they are taking.
Expected behavior
You would expect that the jobs would complete quickly, since nothing has changed and the cache has been populated.
Actual behavior
The jobs build nearly everything from scratch, even when cache entries are found.

The caching also doesn't seem to be working as one would hope within the Docker image builder workflows. There, however, you have an additional caching mechanism to worry about beyond just GitHub Actions cache: the Docker cache.
I believe things are plumbed properly so that Docker will attempt to use GitHub Actions' cache, but the underlying caching problem reported above is surely impacting that as well.

In #164, I've improved the caching situation in regular GitHub Actions some, giving a 30-50% reduction in build times when a cache hit occurs.
To fix the caching problems in Docker, more work is involved. See here for some ideas: https://gist.github.com/noelbundick/6922d26667616e2ba5c3aff59f0824cd

Note for Docker caching problems in CI: It looks like building the Debian-based Docker images does apt install every time instead of ever caching that layer, which invalidates everything following.

The GitHub Cache limit might be part of the problem. I sorted all cache entries by least recently used, and all entries were used within the last day/two (even entries month old). Since we hit the limit, some caching entries are getting removed, reducing their usefulness (I think, but I'm not entirely sure).

I recently split out Vectorscan into its own published crate. Now in the CI jobs, that long-building package can be cached, and cached build job times are all under 2 minutes. For example:
https://github.com/praetorian-inc/noseyparker/actions/runs/8594814073

Relevant discussion I saw over the weekend about caching and Docker builds in GitHub Actions: https://news.ycombinator.com/item?id=39956327. It sounds like the caching scheme we are currently using (GitHub Actions cache for Docker) is doomed, as the cache is too small for the images we are building.
One possible alternative is to use the registry cache mode for the builder job. This will use an external location (like the GHCR registry) for caching, instead of GitHub Actions. Needs investigation.

I experimented a bunch in #169, but failed to find a GitHub Actions incantation that resulted in Docker image builds that actually effectively cached the build stages.
Caching works better now for regular CI jobs, but for jobs that build Docker images, the caching mostly doesn't work at all.

Going back to the matter I brought up earlier, I still think the cache-from directive should be added there. It doesn't create any additional cache but only could use the cache generated by this part. Seems like a small possibility of improvement with no drawbacks.

The other problem I see with changing Docker cache mode to min is that it won't be very effective. Per official docs:

In min cache mode (the default), only layers that are exported into the resulting image are cached

The current Dockerfiles setup will cache only apt-get actions, as the final image is the runner image with the copied binary from the builder phase. To actually leverage caching, I see two options:

Keep min and split builder and runner Dockerfile stages (at least for Debian, Alpine needs to be separated into more stages first) into separate files so each stage is the "final stage." This is a small improvement, but as long as dependencies won't change, it should shave off quite a lot of CI time.
Go back to max and figure out the caching (probably using the registry).

Going back to the https://github.com/praetorian-inc/noseyparker/pull/169#discussion_r1557906813, I still think the cache-from directive should be added there. It doesn't create any additional cache but only could use the cache generated by this part. Seems like a small possibility of improvement with no drawbacks.

Oh, I understand what you're saying about that now. Read from the cache if possible, but don't write to it in release builds. I suspect that it's not going to do anything today in terms of cache benefit. But worth a try.

I experimented with caching for building Docker images some more in #214.
The issues are still issues there:

Using GitHub Actions' cache for the Docker cache results in cache thrashing, as the 10GB limit is not enough for the various CI jobs done by this project
Using the type=registry cache for Docker cache might work, but would fill up our GHCR with intermediate images (there is no retention policy or built-in garbage collection mechanism in GHCR)

Closing this -- someone brave / ambitious can revisit in the future.


Use iteration instead of recursion

Currently, hierarchical data structures are rendered using recursion. Use iteration instead for performance gains and as a preparation for 0.4.x rewrite.

Recursion is not a bottleneck. Closing.


add comparison operators to txt requirements

Allow comparison operators (< and > at the very least, but maybe also !) to requirements operators (mem=>8GB)

Closed with #2


macbook: chrome quit, when close the lid of macbook

What versions are you running?

macos version:
10.14.5

chromedp:
"revision": "f6a51f2349aafd65be469c82cadc7b9e287de363"

$ google-chrome --version
76.0.3809.87

$ go version
go version go1.12 darwin/amd64

What did you do? Include clear steps.
when close the lid of macbook, and reopen the lid, chrome quit
What did you expect to see?
when close the lid of macbook, and reopen the lid, keep chrome alive, don't quit

What happens when you close your macbook's lid? It simply suspends to memory?

What exactly does your chromedp program do when the lid is closed?
Finally, please provide a small program to reproduce this. Otherwise we have to take guesses to try to reproduce the problem.

Friendly ping @ii0; this isn't enough information for us to look into the issue.

Sorry, but I can't debug or fix a bug I can't even reproduce. Closing for now.


Fix named ranges behaviour if cidr_tpl_file variable not provided.

Issue: If factories_config.cidr_tpl_file variable wasn't provided, the code failed.
│ Error: Invalid function argument
│
│   on .terraform/modules/internal_firewall/modules/net-vpc-firewall/main.tf line 50, in locals:
│   50:     can(var.factories_config.cidr_tpl_file) ? yamldecode(file(var.factories_config.cidr_tpl_file)) : {},
│     ├────────────────
│     │ while calling file(path)
│     │ var.factories_config.cidr_tpl_file is null
│
│ Invalid value for "path" parameter: argument must not be null.

Solution: Validate if the variable isn't null (variable's default value) and only then proceed to load the file.

Checklist

I applicable, I acknowledge that I have:

[x] Read the contributing guide
[x] Ran terraform fmt on all modified files
[x] Regenerated the relevant README.md files using tools/tfdoc.py
[x] Made sure all relevant tests pass

Did you really make sure tests pass? I am closing this, can you reopen once tests do not fail?


WIP: 1-cockpit-9: [no-test] Update translations from Fedora Weblate

Update translations from Fedora Weblate

[ ] po-refresh

po-refresh in progress on 1-cockpit-9.
Log: https://logs.cockpit-project.org/logs/po-refresh-1104-20200910-085959/


KEP04: TestStep.Error Feature

TestStep has an error property added which is a list of files.
As stated in KEP04, this will allow the reuse of files in multiple test steps.   This provides a more concise way of expressing this common need.
Example:  01-delete-error.check.yaml
apiVersion: kudo.dev/v1beta1
kind: TestStep
delete:
  - apiVersion: v1
    kind: Pod
error:
  - hello1-error.yaml
  - hello2/hello2-error.yaml```

All the options above have been tested.  The relative path is relative to the step folder the TestStep is in.

Signed-off-by: Ken Sipe<EMAIL_ADDRESS>

reviewer notes:  This PR is work from another branch in #107 but is a PR against master.   This will be rebased after first PR merges.   There is content on this current PR which is from the first.
The true diff is:  https://github.com/kudobuilder/kuttl/compare/ken/teststep-errors...ken/teststep-errors2


ValidateSelfClient could check if the client is expired

Summary
In connection handshakes we can check that the counterparty client we are verifying isn't expired. Not necessary, but would be safe to do

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

I haven't found a ValidateSelfConsensus function anywhere in the code base..., but for ValidateSelfClient would something like the following work?
We could add this code here:
consState, err := k.GetSelfConsensusState(ctx, tmClient.LatestHeight)
if err != nil {
  return sdkerrors.Wrapf(err, "self consensus state not found for height %s", tmClient.LatestHeight.String())
}

if tmClient.IsExpired(time.Unix(0, int64(consState.GetTimestamp())), ctx.BlockTime()) {
  return types.ErrClientExpired
}

where types.ErrClientExpired is added here as:
ErrClientExpired = sdkerrors.Register(SubModuleName, 30, "light client is expired")

@colin-axner @crodriguezvega can I work on this issue?

Thank you, @chandiniv1. We are most likely going to refactor the function ValidateSelfClient in the next couple of months, so this issue might become not relevant. For that reason, I think it's better to hold off and not tackle it just yet.

We discussed and decided to close the issue since we want to eventually remove client state/consensus state validation from the connection handshake.


chore(deps): update dependency google-mobile-ads-sdk to v11.3.0

This PR contains the following updates:

Package
Update
Change

Google-Mobile-Ads-SDK
minor
11.2.0 -> 11.3.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

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

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: renovate-versions.lock
Command failed: bundle exec pod update Google-Mobile-Ads-SDK
Could not locate Gemfile or .bundle/ directory


Track variable sized memory manager allocations through the buffer manager

To follow up the missing part of #3243, this adds BufferManager tracking for variable-sized memory allocations made through the MemoryManager.
I also noticed that the buffer manager wasn't freeing the memory related to evictions if it fails to allocate the total amount of memory requested when claiming a frame. I don't know how much of our code at the moment can safely recover from failing to claim memory and continue allocations though, so it may not make a difference at the moment. I had noticed subsequent failures which seemed to be related to data not being successfully written in the multi copy test that was failing due to not having enough memory in #3557 (e.g. accessing out of bounds in a hash index disk array, which I think would have been in bounds if the data had been updated correctly), so at the moment it may not always be possible to continue using the database after such a failure.

For the tests, do we just want to make sure it's not increasing after queries? In the e2e tests, is there a way of storing and comparing variables? Otherwise it seems like it would be easier to write a C++ test that could check both during and after the memory is allocated, but that wouldn't need a call function (we could have both I guess).
Page caching will also be an issue with that, as unless we also add a way to drop those caches we won't be able to guarantee that the memory usage won't go up or down after a query if new pages are cached, or if old pages are dropped to make space.

For the tests, do we just want to make sure it's not increasing after queries? In the e2e tests, is there a way of storing and comparing variables? Otherwise it seems like it would be easier to write a C++ test that could check both during and after the memory is allocated, but that wouldn't need a call function (we could have both I guess).
Page caching will also be an issue with that, as unless we also add a way to drop those caches we won't be able to guarantee that the memory usage won't go up or down after a query if new pages are cached, or if old pages are dropped to make space.

Yeah, I think we just want to make sure that the mem usage is not going up after re-run same small queries. The case could be we record the mem_usage() after we open the database, then run a small query should bump the mem_usage() a bit higher, but if we run the small query again, the mem_usage should not go up assuming the tables the query touched is small to be fully cached already, and MM always releases its block buffers immediately after it's unpinned.
There isn't a way of storing variables now in testing framework, might be easier to do through CPP instead of Cypher.


Deal with itemPath's changing

Fixes two scenarios:

When an item is deleted and recreated in 1Password with the same name. It would never update the Kubernetes secret unless the itemVersion was different. This will now update the Kubernetes secret as the ItemPathAnnotation will have changed
If you were to edit the OnePasswordItem with a new itemPath, it may have not updated the Kubernetes secret in turn as the item version may also not have been different.

In order to fix this, I've added a check to the if statement to see if the itemPath Annotation has changed. If it has then it'll update the secret! Perfect.

hi guys
any update on this really useful and nice feature?
when do you plan to merge and make it available?
@Marton6  as you worked on features and issues, can you give us any info?

hi guys any update on this really useful and nice feature? when do you plan to merge and make it available?
@Marton6 as you worked on features and issues, can you give us any info?

Hi @bygui86! 👋
Thanks for showing interest in this feature.
This improvement will be made available in the next release of the operator

hi guys any update on this really useful and nice feature? when do you plan to merge and make it available?
@Marton6 as you worked on features and issues, can you give us any info?

Hi @bygui86! 👋
Thanks for showing interest in this feature. This improvement will be made available in the next release of the operator

Thanks for review and merge!


Container support

Okay, we all know that it's not practical for anyone to have all the programming languages installed right? But, what if I had a flag stating that to execute, an alternative command must be executed, that is: a command to be executed in a specific programming language container?
Wow! It would be simply incredible, wouldn't it?
Well, this issue is open for exactly that! Comment here and let's discuss more or open your pull request!

Please assign it to me! We've talked about approaches to this issue, so I could take the lead on it!

Hey @lanjoni. I've done my research and a couple of tests, and I came to a possible solution, which implies on modifications to docker itself.
The library I'll be using is crystal-docker, which doesn't have support for socket based connections e.g: /run/containerd/containerd.sock. Since only TCP based connections are supported for now, a solution I came upon was to modify the startup of the docker daemoni in order to accept TCP connections, which unfortunately implies some security breaches could happen.
What do you think about this? I'm open to ideas.

Hi @J0sueTM!
Perhaps the solution itself is somewhat simpler than running Crystal per container. Well, the advantage of using Crystal is that we can use an executable with the code already compiled.
The main point may be: we don't need a container to run Crystal but we need containers to run the resolutions of other programming languages. Perhaps it would be more practical not to worry about executing a container in Crystal to communicate with others, after all, the compiled one will be executed on the host and will have to upload containers and execute code from other programming languages, also validating the output of each code executed as it is already doing today.
What do you think about that?

Hey, the first PR for this case was merged on https://github.com/lanjoni/hackacrow/pull/15!

Some updates:

Add support to --verbose flag on --docker
Add support to -a (to add arguments instead stdin)

Besides these necessary updates, we've found a couple of things that aren't related first hand to this PR, but still inflicts on it, which are:

Refactor module Run. both functions run_test and run_docker have little differences, so an abstraction would be good
Fix bug on first run. For some reason, if it's the first time a language is being pulled, it doesn't run the tests right away.
Make output from shell commands visible. For example, it would be nice to show the docker pull command visual for the end user.
Test some exotic languages that aren't in the list in lang/lang.json. Maybe add those on demand?


Anti-cheat

There is a very interesting atomic scheme (that PayFile and PayPub also use), it goes like this:

A Sia client wants to download a file
The host deduces a Sia-coin private key from the file hash
The Sia client sends fees to the to the adress of that key
The Sia host hashes the public key to get a secret, and encrypts the file
The Sia client can download this encrypted file for free from the host
If the host spends from that address means he must reveal the public key.
Revealing the public key means he reveals the encryption secret for the file, and the client is happy.
If the host does not spend the coins, the TX is cancelled with a timelock, and nobody is harmed.

I don't quite see the use for this scheme., nor do I see how it's secure.
First, the person doing the encryption is the host. For everything we're currently doing, it's the client that does the encryption. Second, if the client is downloading an encrypted file, how can they be sure that they're getting the file they paid for? What if the host uses some other key to encrypt the file?
I guess this is useful for enforcing that the client pay if the client wants to decrypt the file, but I think there are other better ways of achieving this (micropayments)

They can be sure they get the file they pay for, by requestion the host to send the decryption key for 1 small random chunk after they downloaded the full encrypted file. If that chunk turns out to be the file they expected (and the host cannot know which chunk you would ask), they can be pretty sure that the rest of the file will be too.
This is usefull for releasing the key for one download to many people at once.

I do not believe that the cheating you are concerned about is possible in our current implementation.


Zap add accessors helpers for attributes

Problem
#7027, #7028, #7030 and #7032 are adding code into src/app/clusters for clusters that only contains attributes.
Looking at them, most of the code is about exposing helpers to read/write the attributes.
For TE3 I think we should move forward with them, but I would like to propose an alternative to not have to write cluster code for all accessories that only contains attributes.
Instead of adding code into src/app/clusters, this PR generates accessors for the attributes of the enabled clusters automatically. I would rather prefer to not have to add code to src/app/clusters if this is just to expose helpers.
The helpers for accessing attributes are under a namespace to avoid long names. e.g chip::app:TemperatureMeasurement::Server::GetMeasuredValue.
The current changes for #7027, #7028, #7030 and #7032 and adding them such as emberAfTemperatureMeasurementClusterGetMeasuredValue which does not carry the Server/Client information and also does not allow using usage.
The declarations are grouped into a new gen files into src/app/common/gen/attribute-accessors.h.
This PR also moves APP/gen/callback.h to src/app/common/gen/callback.h and instead of generating declarations for enabled clusters, it generates declarations for all clusters. It requires a ZAP update because some of the cluster names contains characters that are not converted properly by the asCamelCased template helper, such as :, . and #.
Change overview

Introduce src/app/common/gen/attribute-accessors.h
Move APP/gen/callback.h to src/app/common/gen/callback.h
Generate all declarations of callbacks into src/app/common/gen/callback.h since common does not in advance which clusters are enabled and this follow what is done for af-structs.h, enums.h and friends.
Update callback-stubs-src.zapt to generate the accessors code.
Update ZAP to contains some update to asCamelCased. This will probably not work with CI since the commit is still a local commit at that point

Testing

Those changes were tested locally using the all-clusters-app and a modified version of examples/all-clusters-app/linux/main.cpp since nobody uses those methods at the moment.

For fun I pushed a version that does not force the CI to try to checkout my local ZAP commit hash. I would like to see the effects of the changes into callback-stubs.cpp onto the memory of the various example apps.

@vivien-apple do you want me to pick this up?

@bzbarsky-apple yes please!

/rebase

/rebase

I will update this one once #7915 lands. That should makes the diff smaller since many unused attributes won't be part of the generated code anymore.

I have opened #8065 to move callback.h. So this PR will really focus on adding the accessors.

@jmartinez-silabs @msandstedt @LuDuda @Damian-Nordic @selissia ?


[Feature] Flytekit-java, add support for S3

Motivation: Why do you think this is important?
Lot of users at Lyft would love to adopt
https://github.com/spotify/flytekit-java, but today flytekit-java is GCP only. We should add support for S3.
Goal: What should the final outcome look like, ideally?
Python flytekit would be the only way to use Flyte.
Describe alternatives you've considered
NA. Eventually using Flyte-CoPilot would eliminate the need for drivers for each Cloud provider.
Flyte component

[ ] Overall
[ ] Flyte Setup and Installation scripts
[ ] Flyte Documentation
[ ] Flyte communication (slack/email etc)
[ ] FlytePropeller
[ ] FlyteIDL (Flyte specification language)
[x] Flytekit (SDK) - JAVA
[ ] FlyteAdmin (Control Plane service)
[ ] FlytePlugins
[ ] DataCatalog
[ ] FlyteStdlib (common libraries)
[ ] FlyteConsole (UI)
[ ] Other

Additional context
Java usage is increasing within Lyft. This would help a lot of teams at Lyft
Is this a blocker for you to adopt Flyte
NA

+1.
This will be an important feature (and pre-req) for us to use it at Lyft. A lot of data compute in Lyft's data platform is written in Java and we heavily use AWS.

+1 for prioritization

+1

/assign @kanterov

I tested this work, the problem is support for TLS today. I guess once we have TLS support we should be able to start using Flytekit-java at lyft

/assign @spotify/kanterov

This is working, Closing this out

This is working, Closing this out


Better chart

Display gear with favored roll, unfavored roll. Leave empty if neutral.
Chockrit: Flat would be empty, and I don't think many people would care about uncommon rolls cause they're practically not going to get it
Chockrit: But you could list it too
Chockrit: Each gear would have three member abilities: main, common sub, rare sub. And flat rolls could point to Null for flat rolls

fixed with 0854deec12c47c7aa24bdcabc2f469553893d029


[ADD] Prefilled Vault names on Vault Creation

Add prefilled names for different Vault setups, to not have conflicts add incrementing numbers #:
Fast: Fast Vault #
Active: Active Vault #
Secure: Secure Vault #

closing , fixed in #1182


Consider SOURCE_DATE_EPOCH effort

See original issue on GitLab
In GitLab by [Gitlab user @tristanvb] on Oct 5, 2017, 10:37
Debian has done some work towards reproducible builds:
https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal
Apparently many upstreams have been convinced to read this standard variable ensuring that any timestamps are consistent.
Evaluate this, and apply it to our default environment variable configuration

In GitLab by [Gitlab user @tristanvb] on Oct 20, 2017, 09:55
So related reproducible builds spec is at: https://reproducible-builds.org/specs/source-date-epoch/
And presents a challenge which I think should be ignored:

Build systems MUST NOT overwrite this variable for child processes to consume if it is already present.

How is a build system to know ?
Should we set it by default, and have elements clear it with an empty string in the case they know it is used by the element's build scripts ?

In GitLab by [Gitlab user @tristanvb] on Oct 20, 2017, 10:17
closed via commit ea3c76b1b272f7699c6ef32b164881fc7cf591a6

In GitLab by [Gitlab user @tristanvb] on Nov 3, 2017, 13:27
mentioned in commit ea3c76b1b272f7699c6ef32b164881fc7cf591a6


Optimize transaction's graphql queries

During some load tests, we realized a couple of issues (#3279, #3277) that we're fixing and optimizing.
In keeping with this theme, we should continue the effort and review our predefined GQL queries and fragments.
Every field removal is a breaking change and can break things for apps, so we need to be extra careful here.
Taking from the providers/operations.graphql:

[x] getTransaction
[ ] getTransactionWithReceipts
[x] getTransactions
[ ] getTransactionsByOwner
[x] getRelayedTransactionStatus

@Torres-ssf do you think this can be closed as part of #3336 - I can't see any further optimizations.

Closing this issue as the optimizations have already been addressed through the following closed PRs:

https://github.com/FuelLabs/fuels-ts/pull/3336
https://github.com/FuelLabs/fuels-ts/pull/3309
https://github.com/FuelLabs/fuels-ts/pull/3379
https://github.com/FuelLabs/fuels-ts/pull/2962


operator: uninstall operator, keep driver running

What happens when the operator is installed, deploys a driver, and then gets uninstalled?
With the recent change of adding the Namespace object to deploy/kustomize/operator, I suspect that the namespace and thus also the driver will get removed (untested!). This is probably not what we want.
How is that handled when using OLM?

@avalluri: can you check that?

How is that handled when using OLM?

I expect It also supposed to bring down the driver, but slightly with different reason as it deletes the deployment CRD, which leas to delete CR. I will confirm.

I will confirm.

I tired as below sequence of commands:

Install OLM:

$ ./test/start-stop-olm.sh start
....
OLM installation successful!!!
+ /home/avalluri/work/pmem-csi/_work/pmem-govm/ssh.0 kubectl get po -n olm -l app=olm-operator
NAME                           READY   STATUS    RESTARTS   AGE
olm-operator-fb46b989d-75bx9   1/1     Running   0          104s

Start the operator:

$ .TEST_OPERATOR_NAMESPACE=default ./test/start-operator.sh -olm
....
INFO[0047] OLM has successfully installed "pmem-csi-operator.v0.8.0"
....

Install the driver:

$ kubectl create -f deploy/common/pmem-csi.intel.com_v1beta1_deployment_cr.yaml
deployment.pmem-csi.intel.com/pmem-csi.intel.com created
$ kubectl get po
NAME                                                READY   STATUS    RESTARTS   AGE
pmem-csi-intel-com-controller-0                     2/2     Running   0          13m
pmem-csi-intel-com-node-86srl                       2/2     Running   0          7m11s
pmem-csi-intel-com-node-h58sc                       2/2     Running   0          7m17s
pmem-csi-intel-com-node-qn9cs                       2/2     Running   0          15s
pmem-csi-operator-6dd578cb54-s25gl                  1/1     Running   0          16m
pmem-csi-operator-registry-server-665b66586-4gg7s   1/1     Running   0          16m

Uninstall the operator:

$ TEST_OPERATOR_NAMESPACE=default ./test/stop-operator.sh -olm
....
Cleaning up the operator deployment using OLM
+ /home/avalluri/work/pmem-csi/_work/bin/operator-sdk cleanup pmem-csi-operator --namespace default
INFO[0000] subscription "pmem-csi-operator-v0-8-0-sub" deleted
INFO[0000] customresourcedefinition "deployments.pmem-csi.intel.com" deleted
INFO[0003] clusterserviceversion "pmem-csi-operator.v0.8.0" deleted
INFO[0010]  "pmem-csi-operator-catalog" deleted
INFO[0016] operatorgroup "operator-sdk-og" deleted
INFO[0016] Operator "pmem-csi-operator" uninstalled

Check if the driver is running:

$ kubectl get po
No resources found in default namespace.

Let's keep everything as-is and document it as a caveat.

Let's keep everything as-is and document it as a caveat.


speech: add a sink to requestStream so events are not dropped

Coverage remained the same at 99.89% when pulling f11ac4060bcd2f5c056ecb98d0faf4e64f701897 on stephenplusplus:spp--speech-stream-fix into 6a6e76124a43eaf3af386e7d28deb40d3f96d19a on GoogleCloudPlatform:master.

Coverage remained the same at 99.89% when pulling fe69bcc19d3a0df1c9ce041f2085b4aef6a7f1de on stephenplusplus:spp--speech-stream-fix into 6a6e76124a43eaf3af386e7d28deb40d3f96d19a on GoogleCloudPlatform:master.


cant get the scoreboard to dissapear once i pull it up?

i click f10 to pull it up (changed the keybind from f9) and i click it again or click esc and it doesnt go away. how can i fix this and also how can i make it so that i need to hold my keybind for it to show instead of toggling it

F10 does not work in js


distinguish between file and fieldusing content-type

Previously, busboy decided if a part of a request was a file based on the presence of a filename in the part's content disposition, or if the content-type was application/octet-stream. This PR changes that, and now busboy decides based on the presence of the part's content-type header, no matter what mime type it is.
the driving force behind this is that the filename attribute in the part's content-disposition is optional, not required. we are in a situation where a legacy api is posting a file without a filename, which is still a valid form-data request. The spec for multipart/form-data isn't very clear about the difference between a normal form field and one that contains a file, so we decided for our uses to draw the line at the presence of the content-type header.
This means that all parts that trigger a field event will have the default content-type of text/plain, and if users rely on specific content-types for their fields, (like in #106) those will be treated as file events instead.
What are your thoughts? If you decide that this course isn't what you want for the library, then that's okay with us - this just is a bit more clear on what's a file and what's not.

Thanks for the feedback @mscdex. We can (and will) certainly request our API consumer (a mobile app) update their code, and they probably will, but unfortunately we also have to be backwards compatible with existing deployments of the the app. You can reject this PR, however, and we'll see what we can do with dicer or with a manipulation of the headers (to add a default filename) before they reach busboy.


Add more help documentation, automatically generate CLI reference

Adds more help documentation
Adds script to generate CLI reference

Still need to add a lot more documentation. But this is my progress so far.

Ready for review @kadel
Mainly, look at the structure here: https://github.com/cdrage/odo/blob/6710e871e39054b5aa607f55e234de78a969db4e/docs/cli-reference.md
All the other "fluff" in the code is simple edits to cmd help menus. I've also added a script to automatically generate this on each-release.

@kadel Updated. Ready for another review / merge :+1:

@kadel Updated!


Enhanced testing table debugging invalid memory write

It was found that the
Table(Table &tbl);

Constructor was causing resize before initializing the vectors, for some reason this was causing an invalid write error. It was solved by simply removing the resize call which was redundant anyway as the vectors are simply copied over anyway.

The details for the error I was getting from valgrind are here:
==8943== Invalid write of size 1
==8943==    at 0x40626C: table_test::pushback_test::test_method() (in tools/build/src/tests/unit_test_table)
==8943==    by 0x4066FD: table_test::pushback_test_invoker() (in tools/build/src/tests/unit_test_table)
==8943==    by 0x409F76: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (in tools/build/src/tests/unit_test_table)
==8943==    by 0x5154CB0: ??? (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x5134995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x51351B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x5154DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x513C09D: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x51724CA: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x51724CA: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x51379F5: boost::unit_test::framework::run(unsigned long, bool) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==    by 0x5153286: boost::unit_test::unit_test_main(bool (*)(), int, char**) (in /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0)
==8943==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8943==
==8943== Warning: client switching stacks?  SP change: 0x73dafb8 --> 0xffeffeec0
==8943==          to suppress, use: --max-stackframe=68581211912 or greater
unknown location(0): fatal error in "pushback_test": memory access violation at address: 0x00000000: no mapping at fault address
tools/src/tests/test_table.cc(40): last checkpoint

*** 1 failure detected in test suite "table_test"

I have my moments 👍


article outdated

This article is outdated, as it is missing information.
The "-fast" switch is not listed and explained.

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

ID: 4ee8cbc6-02f1-cf6e-99a6-bbd4764a4822
Version Independent ID: 3d394c71-412a-9612-36ca-af84f6e37244
Content: Get-CMPackage - Configuration Manager
Content Source: sccm-ps/ConfigurationManager/Get-CMPackage.md
Product: configuration-manager
Technology: configmgr-other
GitHub Login: @aczechowski
Microsoft Alias: aaroncz

Thanks @EckeD for the feedback. This content is mostly auto generated from what's in the module, but what's currently published is out of date. I have a pending update to bring it up to the latest version.


[FEATURE] Website does not have proper meta tags

Description
Issue: The website does not have important meta tags like keywords, author, language, open graph, etc
Impact: This means that the website is not as visible in search results, and users are less likely to click on the website's links.
Resolution: The website should contain important meta tags. This will help the website rank higher in search results and attract more visitors.

Please assign me this issue so that I can work on this issue under GSSOC'23.


1.1.27 YELLOW&RED

Describe the bug
HI，I am Chinese，My English is not good，So I use translation software
I really like your mod，I hope you will continue to work hard and I will cheer you on！
I've adjusted modlist several times
The hunting problem has been reported wrong in your latest versions
Just click hunt，It will stop for a while，And there are red words
Thank you for your hard work，I will always support you
Error Log
Link to contents of Player.log or Error.log (Please use something like gist or pastebin. DO NOT PASTE HERE)
Player.log
Mod List
Paste contents of ModList used when bug occurred.
Screenshots
If applicable, add screenshots to help explain your problem.

looks like the problem is your modlist. Please take a look at this working modlist: https://github.com/pastorismylord/Community-Modpack/blob/main/Community-modpack-v1.xml

looks like the problem is your modlist. Please take a look at this working modlist: https://github.com/pastorismylord/Community-Modpack/blob/main/Community-modpack-v1.xml


⚠ Bofrost.be has degraded performance

In f6a7599, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1886 ms

Resolved: Bofrost.be performance has improved in 56f9ccd after 6 minutes.


drivers: counter: mcux: Fix sanitycheck test build issue

The generated defines RTC_0_CLOCK_FREQUENCY and RTC_0_PRESCALER are
maked as deprecated by dts generation.  This causes a build warning and
an error during sanitycheck runs.  Replace with the DT_ prefixed
versions that are not deprecated.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

Codecov Report

Merging #13219 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #13219   +/-   ##
=======================================
  Coverage   48.75%   48.75%
=======================================
  Files         319      319
  Lines       46871    46871
  Branches    10835    10835
=======================================
  Hits        22850    22850
  Misses      19394    19394
  Partials     4627     4627

Continue to review full report at Codecov.

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


Unusual comments?

When I add a comment, it is successful but not successful!

my comment just now moved the comment control, isn't it blow the comment control?

Maybe, this li tag should be put into the ul tag, and displayed first comment.

Maybe we can use slots to resolve this problem.

Thanks for finding this bug. Your comments are dynamically appended to the comment list after posting. It's not rendered at the backend. This assertion should be changed to if (request.rid !== 0) {
https://github.com/syhily/yufan.me/blob/cd7863c557816b2139f8cc278887e441fac73f5d/src/assets/scripts/yufan.me.js#L223C19-L223C22


ENH: Unify Raw and Epochs-based covariance

Closes #2867. Related to #2448.
This simplifies our code a bit, and also shows how compute_raw_covariance differed from compute_covariance under the hood.
As shown in the code, compute_raw_covariance has (effectively) keep_sample_mean=False by default, whereas compute_covariance has keep_sample_mean=True by default. This makes me think we should have keep_sample_mean=None -> False with deprecation message saying it will change to True in 0.13. This would really unify the two functions. Thoughts?

Ok your recent arguments convinced me. Seems like a good idea.

@dengemann any opinion on the keep_sample_mean differences? I haven't thought too much about this parameter so I'm not sure what the best thing to do is.

@agramfort any opinion on what to do with keep_sample_mean? It is True for compute_covariance but effectively False (was hidden but now exposed) for compute_raw_covariance. Should we unify them through deprecating False for compute_raw_covariance?

@Eric89GXL I'm wondering which meaning it can have here, as we don't have different conditions in continues mode.

It changes the results a bit depending on whether or not it's enabled

code looks super-clean other than my nitpicks. I haven't seen the details, but I am sure you can discuss it with Denis and Alex.

@dengemann @agramfort I think I figured it out. It turns out that the way we do the computation in master is equivalent to using a single long interval, while throwing out any 0.2-sec (by default) chunks that violate the reject and flat criteria. I think this only coincidentally matched up with what keep_sample_mean=False provided before.
In any case, it means I had to do some tweaks in order to get the old behavior back. Take a look at the new docs and see if they make sense to you, and hopefully the tests show some minor differences.

I could add a kwarg baseline_correct='raw' | 'epochs' or something like that to expose the difference...? Then you could get equivalent behavior to compute_covariance(Epochs(..., make_fixed_length_events(...), baseline=(None, None)) with compute_raw_covariance.

I exposed the baseline parameter to make it clear there are two ways of doing the baseline correction. Also rebased again.

why can we do basleine correction at all here? With continous data this is a weird idea. It should not have such a parameter.

It's how the C code works and how the master version of this code works. Subtracting the mean of the entire data segment is what you'd do to compute the covariance normally, so it's logical to do it.

...or maybe you mean the 'epochs' mode (baseline correct each segment) shouldn't be exposed?

...or maybe you mean the 'epochs' mode (baseline correct each segment) shouldn't be exposed?

yep.

Ahh okay, I'll remove it and put the old explanation that was back in. I didn't hear back on the suggestion from last week so I thought maybe people thought it was reasonable.

Commit reverted, hopefully the explanation makes sense now.

I still don't understand why we need a baseline parameter. In continous mode there is no baseline. Baseline to me is a concept from an event related context and means: the time of non-interest before t0.

There is no baseline parameter now

Cool looks clean to me now.
We should at some point look what kind of results this code gives now across different conditions.

On 22 Feb 2016, at 19:07, Eric Larson<EMAIL_ADDRESS>wrote:
There is no baseline parameter now
—
Reply to this email directly or view it on GitHub.

The only thing I wonder about, is does it matter for the advanced methods whether or not each epoch/segment it processes is actually zero mean? Because in this case it's zero-mean across the concatenation of all epochs, but each individual epoch will have a non-zero mean.

The only thing I wonder about, is does it matter for the advanced methods whether or not each epoch/segment it processes is actually zero mean?

Not sure, we usually standard scale everything. I would have to look it up. Gut feeling it that it may matter if certain parameters are chosen.

you need to rebase

Do you have time to look now? If so I'm happy to rebase. If not, I'd rather wait -- I think I've rebased a couple times already.

@agramfort any idea about whether or not each segment needs to be zero-mean (per channel) to emply the sklearn methods? The way we compute_raw_covariance, the channels are zero-mean across all time and epochs, whereas typically with compute_covariance the channels are zero-mean across time for each epoch individually.

whereas typically with compute_covariance the channels are zero-mean across time for each epoch individually.

but this is not true by default, actually we assume that the data is already zero mean. see assume_centered flags.

but this is not true by default

Ahh, I had assumed that it was assumed to be true, because I was thinking about the use case where epochs were created with baseline=(None, None) (which would imply zero mean per channel per epoch). So it sounds like you're saying that the sklearn reg methods do not require this, which is great.

Ahh, I had assumed that it was assumed to be true,

sorry I mean we assume that the data are zero mean and sklearn will not demean the data.

practically you either filter at 1Hz or so or you baseline before computing the cov.

we assume that the data are zero mean and sklearn will not demean the data.

Hmm, I think we can't guarantee this for compute_raw_covariance. Perhaps we should check for a highpass and only allow non-'empirical' mode if it's e.g. 0.5 or higher?

Perhaps we should check for a highpass and only allow non-'empirical' mode if it's e.g. 0.5 or higher?

This is pretty independent of the other modes, each of them would know how to deal with nonzero mean data. Typically the raw cov should have similar filter settings as your data (at least the manual has been suggesting this). Maybe just a warning. The idea is anyways that you should compute your cov for inverse solutions on roughly zero mean data, it may otherwise produce model violations.

that's it for my nitpicks. Did not test it but I assume you're confident we're good? :)
I just want to avoid breaking something in such a core part of the MNE pipeline.

The old tests still pass and the calculations should be the same as before. The only drawback should be increased memory usage. So yeah I'm happy :)

ok then rebase and make CIs happy then +1 for merge :)


peer_remove: Send user_id, not email, for unsubscribe events.

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

@timabbott The first commit here is ready to merge.  The second commit needs some manual testing, which was complicated by bug #2258.

I was able to test the second commit, so that one is fine too.

Merged after adding that blueslip error, thanks @showell!  I guess the second commit's friend for peer_remove still needs to happen :).


Length property on inline arrays

PCWSTR has a Length property. Do you see the potential for there to be value in adding one to a fixed-length inline array type? What about variable-length inline arrays, when the metadata supports them?

Fixed length, definitely. Wanna send a pull request?
Variable length... maybe. We'll see if the metadata ever describes it.

Sure!

Struct-based GetEnumerator could be fun too, but that's probably too much bloat.

Agreed. Let's leave the enumerator out.


SOLR-17022: Support for glob patterns for fields in Export handler, Stream handler and with SelectStream streaming expression

https://issues.apache.org/jira/browse/SOLR-17022

Description
This PR provides support for using glob patterns for fields in Export handler, Stream handler and with the SelectStream streaming expression. This creates similar ease of use for these handlers as we already have for the Select handler. Given how Solr export handler works, the glob pattern will be applied to only match fields that support stream, which are fields with docvalues enabled.
Solution
This solution uses similar methods to the Select handler to part glob patterns into matching fields. We then create a FieldWriter for each matching field to return the necessary data.
Tests
Implemented tests to ensure that we create the correct set of fields as a results of glob pattern matching.
Checklist
Please review the following and check all that apply:

[X] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[X] I have created a Jira issue and added the issue ID to my pull request title.
[ ] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[X] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[X] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

This seems like a very useful feature!   I also like the establishing parity in how things work.  Will you make sure to update ref guide?

I'm surprised to see that this isn't using SolrReturnFields, which is already doing field glob expansion. I know it's in solr-core and you seem to need something in solrj-streaming but we could move it.

SolrReturnFields was using FilenameUtils.wildcardMatch() from commons-io and this just uses a very similar method but not requiring the third party library and allows solrj-streaming, SolrReturnFields, and ExportWriter to all use the same mechanism to match glob patterns.

My concern is duplication of logic between SolrReturnFields. If you think it's not an issue or is impossible to reconcile, then I trust you.

I finally got back around to this. With the latest change, ExportWriter is using SolrReturnFields which in turn is using GlobPatternUtil so there is a consistent approach there.

@risdenk Pinging for re-review when you have a chance

@justinrsweeney, hello, I'm not sure, but it seems your change causes a significant performance hit with prefixed wildcard fl
https://lists.apache.org/thread/vbwnjxprl6s1qy0t1jzfcw8hprg1gvzh

It's also possible this could be related to SOLR-16989 -- sorry I missed the mailing list thread, I'll follow up there.


Addresses #1259

Swapping out the mann-whitney U-test with a t-test.
Note, this only swaps out this statistical test in the broken test cases.

I was about to complain that swapping a robust Mann–Whitney U test with a t-test doesn't seem valid, then I read your note, and it's just a small test case edit :)
Before changing this I feel we should really understand what changed between versions, as Jai mentioned in #1259. Were the values wrong previously?

I'm not exactly sure what is going on.  Looks like these changes were made in this commit

Thanks! I'll have a look too.

Thanks @mortonjt and @Jorge-C for looking into this. I agree it would be nice to figure out why we're seeing differences between versions. However, mannwhitneyu has had (and still has) a slew of bugs related to tie correction and/or p-values (take a look at issues/PRs related to this function here). IMO mannwhitneyu's buggy behavior is outside the scope of scikit-bio because we aren't advertising usage of mannwhitneyu in the docs and the function was only used in a couple of unit tests to make sure that passing an alternative significance test works as expected. In other words, the user-supplied significance test is buggy but ANCOM is not.
I think this PR is good to go but will hold off on merging in case you guys want more time in tracking down the differences, or if there are any other objections to merging. Thanks again!

I have no objections.  @JorgeC, what do you think?
On Tue, Feb 2, 2016 at 10:45 AM, Jai Ram Rideout<EMAIL_ADDRESS>wrote:

Thanks @mortonjt https://github.com/mortonjt and @Jorge-C
https://github.com/Jorge-C for looking into this. I agree it would be
nice to figure out why we're seeing differences between versions. However,
mannwhitneyu has had (and still has) a slew of bugs related to tie
correction and/or p-values (take a look at issues/PRs related to this
function here
https://github.com/scipy/scipy/search?q=mann&type=Issues&utf8=✓).
IMO mannwhitneyu's buggy behavior is outside the scope of scikit-bio
because we aren't advertising usage of mannwhitneyu in the docs and the
function was only used in a couple of unit tests to make sure that passing
an alternative significance test works as expected. In other words, the
user-supplied significance test is buggy but ANCOM is not.
I think this PR is good to go but will hold off on merging in case you
guys want more time in tracking down the differences, or if there are any
other objections to merging. Thanks again!
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/scikit-bio/pull/1260#issuecomment-178752131.

Thanks a lot for the summary Jai! :+1: from me too (I've restarded the build to see if the timeout disappears).

Sounds good, will merge! Note that master is timing out for Python 3 builds (#1256).


Perplexica UI doesn't terminate initialization

Hi,
Trying Perplexica, it installs without errors, but the UI is stuck before writing its "prompt". It seems its settings must be adjusted, but also the settings page remains stuck waiting with the UPLOAD button disabled:

It seems also that Perplexica doesn't take advantage of the Harbor ecosystem (Ollama, SearXNG).
I got Perplexica working in a dedicated LXC container after setting its config.toml before starting it:
[API_KEYS]
GROQ = "gsk_******"

[API_ENDPOINTS]
OLLAMA = "http://<IP_ADDRESS>:11434"
SEARXNG = "http://<IP_ADDRESS>:4000"

The only harbor config I'm aware of is this:
[root@HarborAI ~]# harbor config ls | grep -i perplexica
PERPLEXICA_HOST_PORT           34041
PERPLEXICA_BACKEND_HOST_PORT   34042

How to solve?
Thank you

Thanks for the report, it's not an expected state, since Perplexica should:

Start from scratch with harbor up perplexica
Connect to built-in Ollama and Searxng out of the box

Unfortunately, Perplexica is one of the services that are a tiny bit "picky" in terms of configuration, I've outlined some most possible caveats here: https://github.com/av/harbor/issues/60#issuecomment-2411864309

The only harbor config I'm aware of

Perplexica (and many other services) cross-connections are setup with cross-service files (I call them x files, haha), here's one for Ollama and another one for SearXNG, these are merged with the rest of the configs whenever harbor sees that matching services are run together (including default services). So one of the things to check is to verify if values in these files match the expected network layout.

I still have the same issue https://github.com/av/harbor/issues/60#issuecomment-2411864309
Also, I noticed that perplexica config survives rm -rf harbor

I managed to solve this same issue I had with Perplexica in a LXC container on Proxmox VE, but I don't know how to apply this solution to Perplexica on Harbor.
After finding this https://github.com/ItzCrazyKns/Perplexica/issues/467, the solution was substituting <IP_ADDRESS> with the LAN IP of the computer runnong Harbor, in my case <IP_ADDRESS>, into docker-compose.yaml:
perplexica-frontend:
    build:
      context: .
      dockerfile: app.dockerfile
      args:
        - NEXT_PUBLIC_API_URL=http://<IP_ADDRESS>:3001/api
        - NEXT_PUBLIC_WS_URL=ws://<IP_ADDRESS>:3001

This requires rebuilding the image, if you are lazy override it on runtime:
  perplexica-frontend:
    image: itzcrazykns1337/perplexica-frontend:main
    restart: unless-stopped
    depends_on:
      - perplexica-backend
    ports:
      - 3000:3000
    networks:
      - perplexica-network
    command: >
      sh -c "
      find .next -type f -name '*.js' -exec sed -i 's|ws://<IP_ADDRESS>:3001|ws://<IP_ADDRESS>:3001|g' {} + &&
      find .next -type f -name '*.js' -exec sed -i 's|http://<IP_ADDRESS>:3001/api|http://<IP_ADDRESS>:3001/api|g' {} + &&
      yarn start"


Add cleanup instructions to the pages that lacked it

Simply the title. I have tried to use multiple syntax to show it to the reader, and also to keep the style consistent. Just notify me if you want any change.

Very nice, thank you @wynro!


Create a how-to guide on terra

On Qiskit docs 2.0 we would like to divide documentation in different types using the diataxis framework. For that, we are creating how-to guides in each Qiskit repo.

@Guillermo-Mijares-Vilarino is going to convert one of the tutorial in qiskit-tutorials to a how-to guide in Terra.

To add the how-to guide example, we will need to add a how-to guide section in the sidebar.


"Parameter does not appear" warning problems

The new warnings introduced by https://github.com/mkdocstrings/griffe/pull/63 (which solves #408) are causing me problems.

The word "parent" is extremely confusing - I assumed it referred to the argument names for a method of the same name in a parent class.
I think it breaks if the method is overloaded and has @overload methods without that argument name.

See https://github.com/samuelcolvin/dirty-equals/pull/32, and this build in particular - the method with the docstring definitely has an argument named expected_kwargs.
The code causing the warning is here
Any chance overloads could be considered, or if not - whether the warning could be optional?

In this particular case, I'll revert griffe to get a new release out.

Ah, I think you simply need to document this parameter using the double stars:
    def __init__(self, expected_value: JsonType = AnyJson, **expected_kwargs: Any):
        """
        Args:
            expected_value: Value to compare the JSON to, if omitted, any JSON is accepted.
            **expected_kwargs (Any): Keyword arguments forming a dict to compare the JSON to,
                `expected_value` and `expected_kwargs` may not be combined.

🙈 that solved it thank you and sorry for the noise.
Tweak to the warning wording would still be a good I think, but I'll close this issue as it's fixed for me.

No problem!
Do you have any suggestions? English is not my native language so my choice of words is always the best :slightly_smiling_face:

I'll change "parent" to "function" since it only works for functions anyway. And add a hint.
                if name not in docstring.parent.parameters:  # type: ignore[union-attr]
                    message = f"Parameter '{name}' does not appear in the function signature"
                    for starred_name in (f"*{name}", f"**{name}"):
                        if starred_name in docstring.parent.parameters:  # type: ignore[union-attr]
                            message += f". Did you mean '{starred_name}'?"
                            break
                    _warn(docstring, line_number, message)

"Function" is perfect, thanks as ever for looking into this.


extend header for 'Cron JOB' detailed list under CMS List

extend header for 'Cron JOB' detailed list under CMS List

done


Write error when specifying output directory

Tried running with the following commands (also had to specify .bed inputs, as I'm also getting the same bamtobed issue reported here):
sicer -t test.bed -c ctrl.bed -s mm10 -cpu 16 -o sicer_out
Normalizing graphs by total island filitered reads per million and generating summary WIG file...

Removing temporary directory and all files in it.
Traceback (most recent call last):
  File "/usr/local/apps/sicer/2-1.0.0/bin/sicer", line 231, in <module>
    main()
  File "/usr/local/apps/sicer/2-1.0.0/bin/sicer", line 225, in main
    run_SICER.main(args)
  File "/usr/local/Anaconda/envs_app/sicer2/1.0.0/lib/python3.6/site-packages/sicer/main/run_SICER.py", line 73, in main
    make_normalized_wig.main(args, output_WIG_name, pool)
  File "/usr/local/Anaconda/envs_app/sicer2/1.0.0/lib/python3.6/site-packages/sicer/src/make_normalized_wig.py", line 46, in main
    with open(outfile_path, 'w') as outfile:
FileNotFoundError: [Errno 2] No such file or directory: 'sicer_out/test-W200-normalized.wig'

Running without the "-o" parameter (i.e. sicer -t test.bed -c ctrl.bed -s mm10 -cpu 16) gives output and my job runs to completion.

Unfortunately, I have the same issue. It is easy to handle the issue on a personal computer but to be able to run the application on a cluster output folder definition becomes necessary.


[docs] Add landing page for GraphQL and fix small typos

Description
Add landing page for GraphQL reference page and fix small typos.
Test Plan

If your changes are not user-facing and do not break anything, you can skip the following section. Otherwise, please briefly describe what has changed under the Release Notes section.
Type of Change (Check all that apply)

[ ] protocol change
[ ] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

Thank you!


[1.10.x] chore: update docs script

Release Note
NONE

Sparing some checks resources, this is going to run at night time only.


[Bug] The interface became very unresponsive and slow after latest updates

Current Behavior
After the last updates it became very slow, almost non-responsive
Expected Behavior
It should run like it's running locally ( like before )
Steps To Reproduce
Just install on a docker and connect to it on web
Environment

OS: Proxmox VE
OS version: 8.2
CPU: Xeon e3-1260
Docker version: 20.10
Device model: ? PC is AMD 5900x with 128 GB memory
Browser/OS: Brave ( Chromium ) / Windows 11

Container creation
version: "2.1"
services:
  jdownloader-2:
    image: jlesage/jdownloader-2
    container_name: jdownloader-2
    volumes:
      - /media/data/usr/local/jd2:/config
      - /media/data/usr/local/jd2/output:/output
      - /snap:/snap
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=pve_bridge"
      - "traefik.http.routers.jd2.rule=Host(`jd2.myextrabeautifuldns.com`)"
      - "traefik.http.routers.jd2.entrypoints=web,websecure"
      - "traefik.http.routers.jd2.tls=true"
      - "traefik.http.routers.jd2.tls.certresolver=production"
      - "traefik.http.services.jd2.loadbalancer.server.port=5800"

    restart: unless-stopped

    networks:
      pub_net:
        ipv4_address: <IP_ADDRESS>
      pve_bridge:

networks:
  pve_bridge:
    external:
      name: pve_bridge
  pub_net:
    external:
      name: pub_net

Container log
[init        ] container is starting...
[cont-env    ] loading container environment variables...
[cont-env    ] APP_NAME: loading...
[cont-env    ] DISPLAY: executing...
[cont-env    ] DISPLAY: terminated successfully.
[cont-env    ] DISPLAY: loading...
[cont-env    ] DOCKER_IMAGE_PLATFORM: loading...
[cont-env    ] DOCKER_IMAGE_VERSION: loading...
[cont-env    ] EGL_LOG_LEVEL: executing...
[cont-env    ] EGL_LOG_LEVEL: terminated successfully.
[cont-env    ] EGL_LOG_LEVEL: loading...
[cont-env    ] GSK_RENDERER: executing...
[cont-env    ] GSK_RENDERER: terminated successfully.
[cont-env    ] GSK_RENDERER: loading...
[cont-env    ] GTK2_RC_FILES: executing...
[cont-env    ] GTK2_RC_FILES: terminated successfully.
[cont-env    ] GTK2_RC_FILES: not setting variable.
[cont-env    ] GTK_THEME: executing...
[cont-env    ] GTK_THEME: terminated successfully.
[cont-env    ] GTK_THEME: not setting variable.
[cont-env    ] HOME: loading...
[cont-env    ] INSTALL_PACKAGES_INTERNAL: executing...
[cont-env    ] INSTALL_PACKAGES_INTERNAL: terminated successfully.
[cont-env    ] INSTALL_PACKAGES_INTERNAL: not setting variable.
[cont-env    ] LIBGL_DRIVERS_PATH: executing...
[cont-env    ] LIBGL_DRIVERS_PATH: terminated successfully.
[cont-env    ] LIBGL_DRIVERS_PATH: loading...
[cont-env    ] PULSE_CONFIG_PATH: executing...
[cont-env    ] PULSE_CONFIG_PATH: terminated successfully.
[cont-env    ] PULSE_CONFIG_PATH: not setting variable.
[cont-env    ] PULSE_COOKIE: executing...
[cont-env    ] PULSE_COOKIE: terminated successfully.
[cont-env    ] PULSE_COOKIE: not setting variable.
[cont-env    ] PULSE_SERVER: executing...
[cont-env    ] PULSE_SERVER: terminated successfully.
[cont-env    ] PULSE_SERVER: not setting variable.
[cont-env    ] QT_STYLE_OVERRIDE: executing...
[cont-env    ] QT_STYLE_OVERRIDE: terminated successfully.
[cont-env    ] QT_STYLE_OVERRIDE: not setting variable.
[cont-env    ] TAKE_CONFIG_OWNERSHIP: loading...
[cont-env    ] XDG_CACHE_HOME: loading...
[cont-env    ] XDG_CONFIG_HOME: loading...
[cont-env    ] XDG_DATA_HOME: loading...
[cont-env    ] XDG_RUNTIME_DIR: loading...
[cont-env    ] XDG_STATE_HOME: loading...
[cont-env    ] container environment variables initialized.
[cont-secrets] loading container secrets...
[cont-secrets] container secrets loaded.
[cont-init   ] executing container initialization scripts...
[cont-init   ] 10-certs.sh: executing...
[cont-init   ] 10-certs.sh: terminated successfully.
[cont-init   ] 10-check-app-niceness.sh: executing...
[cont-init   ] 10-check-app-niceness.sh: terminated successfully.
[cont-init   ] 10-clean-logmonitor-states.sh: executing...
[cont-init   ] 10-clean-logmonitor-states.sh: terminated successfully.
[cont-init   ] 10-clean-tmp-dir.sh: executing...
[cont-init   ] 10-clean-tmp-dir.sh: terminated successfully.
[cont-init   ] 10-fontconfig-cache-dir.sh: executing...
[cont-init   ] 10-fontconfig-cache-dir.sh: terminated successfully.
[cont-init   ] 10-init-users.sh: executing...
[cont-init   ] 10-init-users.sh: terminated successfully.
[cont-init   ] 10-nginx.sh: executing...
[cont-init   ] 10-nginx.sh: terminated successfully.
[cont-init   ] 10-openbox.sh: executing...
[cont-init   ] 10-openbox.sh: terminated successfully.
[cont-init   ] 10-pkgs-mirror.sh: executing...
[cont-init   ] 10-pkgs-mirror.sh: terminated successfully.
[cont-init   ] 10-pulse.sh: executing...
[cont-init   ] 10-pulse.sh: terminated successfully.
[cont-init   ] 10-set-tmp-dir-perms.sh: executing...
[cont-init   ] 10-set-tmp-dir-perms.sh: terminated successfully.
[cont-init   ] 10-vnc-password.sh: executing...
[cont-init   ] 10-vnc-password.sh: terminated successfully.
[cont-init   ] 10-web-data.sh: executing...
[cont-init   ] 10-web-data.sh: terminated successfully.
[cont-init   ] 10-webauth.sh: executing...
[cont-init   ] 10-webauth.sh: terminated successfully.
[cont-init   ] 10-x11-unix.sh: executing...
[cont-init   ] 10-x11-unix.sh: terminated successfully.
[cont-init   ] 10-xdg-runtime-dir.sh: executing...
[cont-init   ] 10-xdg-runtime-dir.sh: terminated successfully.
[cont-init   ] 15-cjk-font.sh: executing...
[cont-init   ] 15-cjk-font.sh: terminated successfully.
[cont-init   ] 15-install-pkgs.sh: executing...
[cont-init   ] 15-install-pkgs.sh: terminated successfully.
[cont-init   ] 55-jdownloader2.sh: executing...
[cont-init   ] 55-jdownloader2.sh: terminated successfully.
[cont-init   ] 85-take-config-ownership.sh: executing...
[cont-init   ] 85-take-config-ownership.sh: terminated successfully.
[cont-init   ] 89-info.sh: executing...
    ╭――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╮
    │                                                                      │
    │ Application:           JDownloader 2                                 │
    │ Application Version:   n/a                                           │
    │ Docker Image Version:  24.09.1                                       │
    │ Docker Image Platform: linux/amd64                                   │
    │                                                                      │
    ╰――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╯
[cont-init   ] 89-info.sh: terminated successfully.
[cont-init   ] all container initialization scripts executed.
[init        ] giving control to process supervisor.
[supervisor  ] loading services...
[supervisor  ] loading service 'default'...
[supervisor  ] loading service 'app'...
[supervisor  ] loading service 'gui'...
[supervisor  ] loading service 'nginx'...
[supervisor  ] loading service 'xvnc'...
[supervisor  ] loading service 'webauth'...
[supervisor  ] service 'webauth' is disabled.
[supervisor  ] loading service 'certsmonitor'...
[supervisor  ] service 'certsmonitor' is disabled.
[supervisor  ] loading service 'audiorecorder'...
[supervisor  ] service 'audiorecorder' is disabled.
[supervisor  ] loading service 'openbox'...
[supervisor  ] loading service 'pulseaudio'...
[supervisor  ] service 'pulseaudio' is disabled.
[supervisor  ] loading service 'xcompmgr'...
[supervisor  ] loading service 'logmonitor'...
[supervisor  ] service 'logmonitor' is disabled.
[supervisor  ] loading service 'logrotate'...
[supervisor  ] all services loaded.
[supervisor  ] starting services...
[supervisor  ] starting service 'xvnc'...
[xvnc        ] Xvnc TigerVNC 1.13.1 - built Aug 31 2024 13:06:50
[xvnc        ] Copyright (C) 1999-2022 TigerVNC Team and many others (see README.rst)
[xvnc        ] See https://www.tigervnc.org for information on TigerVNC.
[xvnc        ] Underlying X server release 12014000
[xvnc        ] Fri Nov  8 07:41:06 2024
[xvnc        ]  vncext:      VNC extension running!
[xvnc        ]  vncext:      Listening for VNC connections on /tmp/vnc.sock (mode 0660)
[xvnc        ]  vncext:      Listening for VNC connections on all interface(s), port 5900
[xvnc        ]  vncext:      created VNC server for screen 0
[supervisor  ] starting service 'nginx'...
[nginx       ] Listening for HTTP connections on port 5800.
[supervisor  ] starting service 'openbox'...
[supervisor  ] starting service 'xcompmgr'...
[supervisor  ] starting service 'app'...
[supervisor  ] all services started.
[xvnc        ] Fri Nov  8 07:41:20 2024
[xvnc        ]  Connections: accepted: /tmp/vnc.sock
[xvnc        ]  SConnection: Client needs protocol version 3.8
[xvnc        ]  SConnection: Client requests security type None(1)
[xvnc        ]  VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian rgb888
[xvnc        ]  VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian bgr888
[xvnc        ]  ComparingUpdateTracker: 0 pixels in / 0 pixels out
[xvnc        ]  ComparingUpdateTracker: (1:-nan ratio)

Container inspect
[
    {
        "Id": "e394726ebcf2f96983b89f401cf34833f1465ae94fff919495c3c2142c53c815",
        "Created": "2024-11-08T07:40:58.242096172Z",
        "Path": "/init",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 2197397,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2024-11-08T07:40:59.647894148Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
        "Image": "sha256:e58375eb19550f75ee947b08e09db835b84be55337bfe8d7af9bc29c1d5eb17d",
        "ResolvConfPath": "/var/lib/docker/containers/e394726ebcf2f96983b89f401cf34833f1465ae94fff919495c3c2142c53c815/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/e394726ebcf2f96983b89f401cf34833f1465ae94fff919495c3c2142c53c815/hostname",
        "HostsPath": "/var/lib/docker/containers/e394726ebcf2f96983b89f401cf34833f1465ae94fff919495c3c2142c53c815/hosts",
        "LogPath": "/var/lib/docker/containers/e394726ebcf2f96983b89f401cf34833f1465ae94fff919495c3c2142c53c815/e394726ebcf2f96983b89f401cf34833f1465ae94fff919495c3c2142c53c815-json.log",
        "Name": "/jdownloader-2",
        "RestartCount": 0,
        "Driver": "overlay2",
        "Platform": "linux",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "docker-default",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": [
                "/media/data/usr/local/jd2/output:/output:rw",
                "/media/data/usr/local/jd2:/config:rw",
                "/snap:/snap:rw",
            ],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "json-file",
                "Config": {}
            },
            "NetworkMode": "pub_net",
            "PortBindings": {},
            "RestartPolicy": {
                "Name": "unless-stopped",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": [],
            "CapAdd": null,
            "CapDrop": null,
            "CgroupnsMode": "private",
            "Dns": null,
            "DnsOptions": null,
            "DnsSearch": null,
            "ExtraHosts": null,
            "GroupAdd": null,
            "IpcMode": "private",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "NanoCpus": 0,
            "CgroupParent": "",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": null,
            "DeviceCgroupRules": null,
            "DeviceRequests": null,
            "KernelMemory": 0,
            "KernelMemoryTCP": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": null,
            "OomKillDisable": null,
            "PidsLimit": null,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0,
            "MaskedPaths": [
                "/proc/asound",
                "/proc/acpi",
                "/proc/kcore",
                "/proc/keys",
                "/proc/latency_stats",
                "/proc/timer_list",
                "/proc/timer_stats",
                "/proc/sched_debug",
                "/proc/scsi",
                "/sys/firmware"
            ],
            "ReadonlyPaths": [
                "/proc/bus",
                "/proc/fs",
                "/proc/irq",
                "/proc/sys",
                "/proc/sysrq-trigger"
            ]
        },
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/c5124df0aa506fdc170c23c1919ddddc56e6bb69ab2a4a5fda70cb53de62b2cc-init/diff:/var/lib/docker/overlay2/1a91e31c98698836914ee0b447e76ff06c081803cc452a0dca52a60c49a71504/diff:/var/lib/docker/overlay2/3d5cebd7aa67437cee520a708c40cf521d43f3eaf3f4545da638095fd9c4b9be/diff:/var/lib/docker/overlay2/72c0848f7cf732f50016376d7a8e7a593f2b6b6315b760e8116473d54c9e0283/diff:/var/lib/docker/overlay2/b35980443f0783fad26f2b6522fd873cfd8687a0e9d23bf77c77e36cec3d35c6/diff:/var/lib/docker/overlay2/522a8a9b518a28f2de20ce86c6adacbc2f74301780b1a91a8fad76882cf820fb/diff:/var/lib/docker/overlay2/cac0d398d5ffd40b22e725856d91004d6ff30317531954aa41720ace136535e8/diff:/var/lib/docker/overlay2/96bc8b4011ced9a13e369d876b3679e52ab435b89878b3b8f106259f0932d79d/diff:/var/lib/docker/overlay2/8db967041b063ef6370b2057972f31ccdd1def7a293ed97a494764c48a4204c2/diff:/var/lib/docker/overlay2/3004886b81970d8447958345c28b3591b2cf06cb325eb240d4bfb5078b4dd4ae/diff:/var/lib/docker/overlay2/2a7f4e5bd8f15d5e0e95b97ad51a4bf23f8209546e43680e034cf36f43849840/diff:/var/lib/docker/overlay2/2e402e5ee519a843afada41ecc112846f773d7671693b71605e540e33d412a4a/diff:/var/lib/docker/overlay2/85a6139bf55ab98fa53590ba0be0296e8d2ff77f4956ab183fc12dc344bf2bdb/diff:/var/lib/docker/overlay2/ce44a36550828903a5846c9ae8d715f442227535afeb2f9875ba63c82df99025/diff:/var/lib/docker/overlay2/9965b09eb0ddda40a2b02c219bce31adc4df5aa48d9ecc3a436b29edbe468f65/diff:/var/lib/docker/overlay2/0a42100d1c623213717a9c0adc3741e590750428ad7ec74f16cb0d5e6848b6b6/diff:/var/lib/docker/overlay2/e88d480400f0b95f811259db90722d27a37d13ffbc8112e4adc9ce1431fbf64b/diff:/var/lib/docker/overlay2/eabd7fcd798f921578ee2d5c72cf9a0e0f614caa9144ee065d6158b26d34a2a5/diff:/var/lib/docker/overlay2/3e5bbf8f534e2a7de33255d1bdfdb8b39468e857e5c8e7e0117198d497ff5d24/diff:/var/lib/docker/overlay2/00c1ce8f00d36325e06cdccc48020ef29a3b87d4b8fba9db49709e5480219670/diff:/var/lib/docker/overlay2/a597b0bac853afd79234655c0e176d33ea3336974e50334c77c41a65c6e2b8cb/diff:/var/lib/docker/overlay2/9b7468d8a4a63ced8e63b8208f6d240335bd06f6a4f41344c7322c5ab697c266/diff:/var/lib/docker/overlay2/cfff0892c6ebec805fc898f796ea1a5527bdd3624214baa5e2fe7cf384a07ec1/diff:/var/lib/docker/overlay2/9a2054dc6bed423040d57246b8ae47ad5c6be3c5e793360c43374c6b79868cbf/diff:/var/lib/docker/overlay2/4ed3b603a5951cd6e2c9aabcf18de82a61b12340b84028081abe6dd3c406fe25/diff:/var/lib/docker/overlay2/1ee426553cab4a21859d8682e3f292f173b54e5ca74ee08c1612a0eed6c8795e/diff:/var/lib/docker/overlay2/2d5e16c9150a1c1f242c9f7e4baf4a426e451d336c9377e2ab7a6ff9705e3527/diff:/var/lib/docker/overlay2/64264045ea9ee61aadc920ae7947e757904a660720db76b8902f8c775d747399/diff:/var/lib/docker/overlay2/15e2f7845ecfe7947be117c63259a2c33e78fc6b99bd5066ec6553a1b455273d/diff:/var/lib/docker/overlay2/d439c19fac52b5283bab45ddfc01df08ec78f45cc83797b2f08cd46b199017d8/diff:/var/lib/docker/overlay2/533d7b9597b66e1d89051aed0be9e26ac33f6229bf936687693a0b743c8f0ee3/diff:/var/lib/docker/overlay2/662a4d3bee093b168848f65c0d493de3205f90e5730b199dfe78c51b11a929c3/diff:/var/lib/docker/overlay2/7824e4e121f1e7449a3085b414d97570fd7c29898849e8a7ea9506f0197fbfee/diff:/var/lib/docker/overlay2/299fc5ffccea26f70d5c4624e0c539db279d26997932df4a9a19e8d6eff078db/diff:/var/lib/docker/overlay2/8b900b85946b62c1e4bbdb72ea0e032d90accb590450c817a44fcf2b47901315/diff:/var/lib/docker/overlay2/bb11828d6cf786caa5805f42abf22eddd6a064155cdf49100a4050aca143af55/diff:/var/lib/docker/overlay2/dfe71665d9dab935042bd0a3eef403ae221a0458c12e8ecb2e437d2ebc05070f/diff:/var/lib/docker/overlay2/6832e9949a3d830e5bec6091839274d4ac5bfbacf89cb2abee1f338346c5fafe/diff:/var/lib/docker/overlay2/41045e598b6e979e22d1c857ed721292418807cb027be98db1e3147ed4cf5c7d/diff:/var/lib/docker/overlay2/921c54ef68c8fc84224aaf8e69bca69f931daa829e5e38a8faf1b725755c16a0/diff:/var/lib/docker/overlay2/d556956cec903e973170058f47c201867080a14876f71a74a0484865103ff9cb/diff:/var/lib/docker/overlay2/a71776e01de2550efa52f862b22357c5d71ddca267175f0ac4fa41fdec854242/diff",
                "MergedDir": "/var/lib/docker/overlay2/c5124df0aa506fdc170c23c1919ddddc56e6bb69ab2a4a5fda70cb53de62b2cc/merged",
                "UpperDir": "/var/lib/docker/overlay2/c5124df0aa506fdc170c23c1919ddddc56e6bb69ab2a4a5fda70cb53de62b2cc/diff",
                "WorkDir": "/var/lib/docker/overlay2/c5124df0aa506fdc170c23c1919ddddc56e6bb69ab2a4a5fda70cb53de62b2cc/work"
            },
            "Name": "overlay2"
        },
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/media/data/usr/local/jd2",
                "Destination": "/config",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/media/data/usr/local/jd2/output",
                "Destination": "/output",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/snap",
                "Destination": "/snap",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
        ],
        "Config": {
            "Hostname": "e394726ebcf2",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "3129/tcp": {},
                "5800/tcp": {},
                "5900/tcp": {}
            },
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/base/sbin:/opt/base/bin",
                "ENV=/root/.docker_rc",
                "USER_ID=1000",
                "GROUP_ID=1000",
                "SUP_GROUP_IDS=",
                "UMASK=0022",
                "LANG=en_US.UTF-8",
                "TZ=Etc/UTC",
                "KEEP_APP_RUNNING=0",
                "APP_NICENESS=0",
                "INSTALL_PACKAGES=",
                "PACKAGES_MIRROR=",
                "CONTAINER_DEBUG=0",
                "DISPLAY_WIDTH=1920",
                "DISPLAY_HEIGHT=1080",
                "DARK_MODE=0",
                "SECURE_CONNECTION=0",
                "SECURE_CONNECTION_VNC_METHOD=SSL",
                "SECURE_CONNECTION_CERTS_CHECK_INTERVAL=60",
                "WEB_LISTENING_PORT=5800",
                "VNC_LISTENING_PORT=5900",
                "VNC_PASSWORD=",
                "ENABLE_CJK_FONT=0",
                "WEB_AUDIO=0",
                "WEB_AUTHENTICATION=0",
                "WEB_AUTHENTICATION_DEFAULT_USERNAME=",
                "WEB_AUTHENTICATION_DEFAULT_PASSWORD=",
                "MYJDOWNLOADER_EMAIL=",
                "MYJDOWNLOADER_PASSWORD=",
                "MYJDOWNLOADER_DEVICE_NAME=",
                "JDOWNLOADER_HEADLESS=0",
                "JDOWNLOADER_MAX_MEM="
            ],
            "Cmd": [
                "/init"
            ],
            "Image": "jlesage/jdownloader-2",
            "Volumes": {
                "/config": {},
                "/output": {},
                "/snap": {},
            },
            "WorkingDir": "/tmp",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "com.docker.compose.config-hash": "4de31c146c2afa926981d1af3a6d236779d06c4ed03a2dfff00c0de8e67cfd07",
                "com.docker.compose.container-number": "1",
                "com.docker.compose.oneoff": "False",
                "com.docker.compose.project": "jdownloader",
                "com.docker.compose.project.config_files": "docker-compose.yaml",
                "com.docker.compose.project.working_dir": "/root/dev/.docker/jdownloader",
                "com.docker.compose.service": "jdownloader-2",
                "com.docker.compose.version": "1.29.2",
                "org.label-schema.description": "Docker container for JDownloader 2",
                "org.label-schema.name": "jdownloader-2",
                "org.label-schema.schema-version": "1.0",
                "org.label-schema.vcs-url": "https://github.com/jlesage/docker-jdownloader-2",
                "org.label-schema.version": "24.09.1",
                "traefik.docker.network": "pve_bridge",
                "traefik.enable": "true",
                "traefik.http.routers.jd2.entrypoints": "web,websecure",
                "traefik.http.routers.jd2.rule": "Host(`jd2.myextrabeautifuldns.com`)",
                "traefik.http.routers.jd2.tls": "true",
                "traefik.http.routers.jd2.tls.certresolver": "production",
                "traefik.http.services.jd2.loadbalancer.server.port": "5800"
            }
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "dd6ce58583f2d48549f5165899a31503cda4ca1a7a302bfaabc0319d2b51fb2a",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {},
            "SandboxKey": "/var/run/docker/netns/dd6ce58583f2",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {
                "pub_net": {
                    "IPAMConfig": {
                        "IPv4Address": "<IP_ADDRESS>"
                    },
                    "Links": null,
                    "Aliases": [
                        "jdownloader-2",
                        "e394726ebcf2"
                    ],
                    "NetworkID": "29fdfc2d1c7c7cb04e63e8eabf4158851f4d69ea031968e3164aef7240508065",
                    "EndpointID": "5a743de41b58d0d95b9f20f1f83ec99b9fa6c09f07158fb8ef5839efe5765ba7",
                    "Gateway": "<IP_ADDRESS>",
                    "IPAddress": "<IP_ADDRESS>",
                    "IPPrefixLen": 24,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:c0:a8:01:d7",
                    "DriverOpts": null
                },
                "pve_bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": [
                        "jdownloader-2",
                        "e394726ebcf2"
                    ],
                    "NetworkID": "8cbe3773c883f67fc7ad1329af42dcbc010c5c3064cf86b068bd853cb35d889b",
                    "EndpointID": "23986dcb333b2e0ab0e84446b61e460aaa50c8a19ad961d06f437af10f353d92",
                    "Gateway": "<IP_ADDRESS>",
                    "IPAddress": "<IP_ADDRESS>",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:14:00:0c",
                    "DriverOpts": null
                }
            }
        }
    }
]

Anything else?
No response

You mean after an update of the container image or an update JDownloader itself ?

It was after an update.
I also restarted container a few times, and it was sluggish every time.
Though right now it's ok.
I believe there's something causing interface to become almost non-responsive, but I couldn't find the cause yet. I'm closing the issue. If I find the real cause I'll reopen it.
PS. I'm connecting to the interface via 2,5Gbps LAN connection  ( both on PC and NAS ). So the network speed was not an issue.


[MM-22751] Removed Windows 10 style border for non-Windows 10 clients

Before submitting, please confirm you've

[x] read and understood our Contributing Guidelines
[x] completed Mattermost Contributor Agreement
[x] executed npm run lint:js for proper code formatting

Please provide the following information:
Summary
This PR adds the original window border for non-Mac, non-Windows 10 clients so that the window style more accurately fits the OS being used.
This has been tested on:

Windows 7 SP1
Ubuntu 20.04 LTS
Fedora 31

More testing on other operating systems should happen before this is merged.
Issue link
https://mattermost.atlassian.net/browse/MM-22751

This really should be a choice that is pre-populated with the platform check.


Password-protected Pages: owners & content review

Hi, I believe that since https://github.com/wagtail/wagtail/pull/7385 this is no longer an issue, is that right?


Add support for DELETE requests

Have been using this library now for a few hours and seems to work very well and the implementation is simple so it's a joy to use. The examples were very useful!
I do need to do a DELETE request however and that does not seem to be implemented.
I am very new to Rust but it should be rather simple to implement.
I just wanted to tell you that if you do not intend implement this yourself soon, I might in a few weeks when I get more time.

I have been using restson with Snipe-IT's API without any issues up until now (so thanks for that!).
However now I've come to realize that this API would need a delete_capture method. They have a philosophy of always returning 200 unless the server itself fails.
So without capture there's no way of telling whether it actually worked.
I have no idea how common practice this is.

Hi @StarlessNights !
I originally left delete_capture out since I thought that it would be very uncommon to have response body in DELETE requests. Though, adding that interface is a straighforward task so I now added both delete_capture and delete_capture_with. I just published these changes to v1.5.0 in crates.io.