There is no vbback in old ASP

My solution.
dim vbback
vbback = Chr(8)

Thank you.
I'll fix that soon.

I think something went wrong with this fix in commit 86f0f5999586da462fe0c41540be8732b6068dc6. First of all the use of vbback is still in the code and the code to replace the tab character was changed in a way that causes a compilation error. char(8) is invalid and should be chr(9) (i.e. without the 'a' and '9' instead of '8').


Multi-slider for Native Base

Hi!
Not sure if this has been suggested yet, but I think a multi-slider would be a good addition to this framework.  I saw that Sliders were on the Roadmap, I just thought I would throw this in as well?
I can try to code up something for a pull request if this hasn't been accounted for already? :)

@mjohns39 PR would be of help!

#38


Refactor to use Kafka message interface so internal implementation can use rest proxy without copy pasting code

Close since we are working on kafka deprecation and this will be irrelevant.


How to get the swipe animation programmatically?

Hi,
I noticed that when you entered a valid credit card number, exp date and CVV and you go back to the credit card field, exp date and CVV fields disappear. One way to see them again is to swipe in the text field, but I'd like to programmatically trigger the same animation when the card number text field becomes first responder. Any ideas on how to do that?
Thanks!

Hi,
these methods are currently internal to Caishen.
You can, however, access them by calling the selectors directly via
cardTextField.performSelector(Selector("moveNumberFieldLeft"))

cardTextField.performSelector(Selector("moveNumberFieldLeftAnimated"))

cardTextField.performSelector(Selector("moveNumberFieldRight"))

cardTextField.performSelector(Selector("moveNumberFieldRightAnimated"))

Note: The moveNumberFieldLeft and moveNumberFieldLeftAnimated functions will only perform the change if the card number has been entered and is valid.

Hi @DannyVancura,
Selector is deprecated with Xcode 7.3, and if I use the new #selector it requires to provide the function instead of a string, but because it's internal I can't access it.

@ThibaultKlein Thanks for pointing this out. I created a pull request to make these methods public. I also renamed them to move card number out or in.
This PR will give you access to moveCardNumberOut, moveCardNumberOutAnimated, moveCardNumberIn and moveCardNumberInAnimated.
As before: moveCardNumberOut and moveCardNumberOutAnimated will do nothing as long as the card number is not valid, simply because the moveCardNumberOut animation is supposed to show the last four digits of the card number, which only makes sense for a complete card number.


Docker bypasses NixOS firewall exposing ports on the external interface

Using virtualisation.oci-containers.containers.<name>.ports exposes ports on the external interface regardless of firewall settings.
Docker injects its own firewall rules, bypassing the NixOS firewall.
To Reproduce
Configure a container and use the ports option:
{
  virtualisation.oci-containers.containers.foo = {
    # Other settings here ...
    ports = [ "8123:8123" ];
  };

  networking.firewall = {
    enable = true;
    allowedTCPPorts = lib.mkForce [ ];
    allowedUDPPorts = lib.mkForce [ ];
  };
}

Expected behavior

Port 8123 on the host will forward to the same port on the container (this works)
Port 8123 on the host blocked from external access via the firewall (Docker is bypassing this)

Additional context
My iptables skills are lacking, but I think this rule, created by Docker, is the problem:
  -A DOCKER -d <IP_ADDRESS>/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8123 -j ACCEPT

This was brought up in 2018 via #40507 but it looks like GitHub has deleted some comments and it's not clear why the issue was closed.
Notify maintainers

~@adisbladis~
@offlinehacker @tailhook @vdemeester @periklis
Metadata

system: "x86_64-linux"
host os: Linux 5.9.16, NixOS, 20.09pre-git (Nightingale)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.10
nixpkgs: /nix/store/3p4q8xc5y9kr57ysmd0s2s20s174pg23-a058d005b3cbb370bf171ebce01839dd6ff52222.tar.gz

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
  - virtualisation.oci-containers.containers

@siers Could you shed some light on why #40507 was closed?
Thank you.

I recommend using the podman backend for oci-containers instead. This will honour firewall rules.

@adisbladis I agree that using podman is the preferred solution.
To resolve this particular bug either Docker needs to be removed as an oci-containers backend or if the ports option is used then Docker's firewall rules should be disabled and correctly crafted firewall rules inserted in their place.

@pjones I think I thought it's going to be a "wontfix", but it doesn't warrant closing of the issue, in hindsight.

I've worked around this using  extraCommands in firewall config (docker-way to filter container traffic is to use DOCKER-USER chain):
iptables -F DOCKER-USER
iptables -A DOCKER-USER -i <external_iface> -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A DOCKER-USER -i <external_iface> -j DROP

This allows traffic originating from container to work but connectivity from outside is filtered.
I'm a total nixos newbie but having something similar by default when firewall is enabled and docker installed and adding rules based on some options etc would allow people to use docker safely?

Could someone add a severity:security label? This could be really bad if someone is unaware that they're exposing something externally

I had the same issue using the podman backend. Are you sure that podman works properly?

This seems to be an issue with podman as well. I'm no expert in iptables, but it seems podman handles container's rules through FORWARD table, therefore INPUT rules like open ports are completely ignored. FORWARD default policy is ACCEPT, so everything gets accepted. podman also creates a few chains to handle this (CNI-FORWARD, CNI-ADMIN), so I managed to filter my container's input with something like this:
  networking = {
    firewall = {
      ...
      extraCommands = ''
        ip46tables -P FORWARD DROP
        iptables -N CNI-ADMIN || true
        iptables -A CNI-ADMIN -p tcp -m multiport --dports 30303,30304 -j nixos-fw-accept
        iptables -A CNI-ADMIN -p udp -m multiport --dports 30303,30304 -j nixos-fw-accept
      '';
      extraStopCommands = ''
        iptables -D CNI-ADMIN -p tcp -m multiport --dports 30303,30304 -j nixos-fw-accept || true
        iptables -D CNI-ADMIN -p udp -m multiport --dports 30303,30304 -j nixos-fw-accept || true
        ip46tables -P FORWARD ACCEPT
      '';
    };
  };

Just want to add that I believe you can disable this behavior by instructing the docker daemon not to manage iptables.
This can be done by passing the following arguments to dockerd
      --iptables                              Enable addition of iptables rules (default true)
      --ip6tables                            Enable addition of ip6tables rules (default false)

In a configuration.nix file it can be set as follows:
virtualisation.docker.extraOptions = ''--iptables=false --ip6tables=false';

You can verify the additional flags have been passed via ssystemctl status docker | grep "libexec/docker/dockerd"
You may need to flush iptables rules to see this take effect, I believe that can be achieved by restarting. There may be another way to flush the rules without restarting but I'm not sure how to do this in NixOS.
More info at:
https://docs.docker.com/network/iptables/#prevent-docker-from-manipulating-iptables

In the most common case, you don't even need to disable Docker's iptables integration or add custom config to your iptables - you can simpliy specify the port binding as "<IP_ADDRESS>:8123:8123" instead of "8123:8123". Then it will only listen on localhost.

Just want to add that I believe you can disable this behavior by instructing the docker daemon not to manage iptables.
This can be done by passing the following arguments to dockerd:
      --iptables                              Enable addition of iptables rules (default true)
      --ip6tables                            Enable addition of ip6tables rules (default false)

In a configuration.nix file it can be set as follows:
virtualisation.docker.extraOptions = ''--iptables=false --ip6tables=false';

You can verify the additional flags have been passed via ssystemctl status docker | grep "libexec/docker/dockerd"
You may need to flush iptables rules to see this take effect, I believe that can be achieved by restarting. There may be another way to flush the rules without restarting but I'm not sure how to do this in NixOS.
More info at:
https://docs.docker.com/network/iptables/#prevent-docker-from-manipulating-iptables

No, this can fup container communcations, e.g. no internet/dns inside containers.

I ran across this issue today - this is a problem which needs a solution, or at least a warning. The firewall is basically broken in certain situations, and if I didn't test access I would be unaware. https://nixos.wiki/wiki/Firewall does not mention that the firewall doesn't work with docker images.

Woah. This is a massive footgun. Maybe we should also add a warning message in the terminal if networking.firewall.enable && virtualisation.docker.enable. Should be pretty easy with this: https://github.com/NixOS/nixpkgs/blob/69a35ff92dc404bf04083be2fad4f3643b2152c9/nixos/doc/manual/development/assertions.section.md#warnings-sec-assertions-warnings

Potential solution here. Perhaps a toggle to add said rules is required: https://github.com/chaifeng/ufw-docker

I just stumbled on this with podman which also exhibits this behaviour which is as design and in line with Docker and CNI: https://github.com/containers/podman/issues/15623
The rules for this reside in the NAT iptables table (see https://www.cni.dev/plugins/current/meta/portmap/#dnat) instead of the FILTER table where Docker does its thing.
The best solution seems to use explicit IP's in port mapping <IP_ADDRESS>:8080:8080 or insert rules into the NAT chains.

For me, it worked using <IP_ADDRESS>:8080:8080. It also allowed me to use NGINX outside Docker on port 80.

For me, it worked using <IP_ADDRESS>:8080:8080. It also allowed me to use NGINX outside Docker on port 80.

<IP_ADDRESS> means, everything is allowed, from anywhere.
The real Docker centric workaround for this is to use <IP_ADDRESS>:8080:8080 as mentioned in the previous comment.

Disable iptables in docker daemon setting is the simplest workaround i think.

https://docs.docker.com/network/packet-filtering-firewalls/ has a couple of different solutions for this.
Setting virtualisation.docker.daemon.settings = { ip = "<IP_ADDRESS>"; }; sets "the default bind address for containers" to localhost, making this less of a footgun.  Unfortunately this "doesn't have any effect on Swarm services. Swarm services are always exposed on the <IP_ADDRESS> network interface." (and docker-compose behaves the same).
Since I regularly use docker-compose, I additionally blocked external traffic in the Docker chain.
(If the machine running Docker is also a router, you'll want to add rule(s) to not block legitimate traffic before the DROP rule - I leave these out here)
networking.firewall.extraCommands = ''
  iptables -N DOCKER-USER || true
  iptables -F DOCKER-USER
  iptables -A DOCKER-USER -i <external-if> -j DROP
  iptables -A DOCKER-USER -j RETURN
'';

Eventually the easiest way would be to enforce user setting docker.exposePortsIptables = true/false which passes the dockerd options. Then user must turn aware of it.


List out of bounds in nexis_rtf_extract

Hi,
I am kind of a rookie in programming, but I found an error in the code and fixed it. I probably didn't fix it very good, and I should probably not post this here, but maybe it helps some people.
Sometimes the date is not in nex_split[2] but in nex_split[3], which gives a list out of bounds error. So i wrote this:
if re_date_nu.findall(nex_split[2]) == []:       date_str = re_date_nu.findall(nex_split[3])[0] else:       date_str = re_date_nu.findall(nex_split[2])[0]

Thanks!


Add tls ssl key endpoints to traffic_ops_golang.

This PR adds 3 API endpoints to the traffic_ops_golang, from CDN-750.  The endpoints add certificates to RIAK and  fetch certificates from RIAK by hostname and xmlid.  The add function verifies and orders the certificate chain before storing to RIAK.
Talked to @dewrich and since these endpoints do not yet implement tenancy checks they are marked as "-wip" in the routes.go.  Will implement tenancy at a later date.  Want to get this in to avoid merge conflicts going forward.

SUCCESS
No test results found.
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/664/
Test PASSed.

SUCCESS
No test results found.
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/666/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/623/

SUCCESS
No test results found.

SUCCESS
No test results found.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/625/

SUCCESS
No test results found.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/635/

FAILURE
No test results found.
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/676/
Test FAILed.


Doesn't Work for Freebsd Platform

Freebsd it doesn't work. The workaround is to open the  include/os_detector and modify the 16th line from
if [ "$OSTYPE" == "linux-gnu" ] || [ "$OSTYPE" == "linux-musl" ]; then
To
if [ "$OSTYPE" == "linux-gnu" ] || [ "$OSTYPE" == "linux-musl" ] || ["$OSTYPE" == "freebsd" ]; then

Nice, thanks @farhancitrix, I'll add it to devel branch so far. But PR are welcome ;)

@farhancitrix I added it to devel, can you check it and let me know please?

I added it to devel and merged to master and I found and issue on it when running Prowler on OSX:
./include/os_detector: line 16: [darwin18.2.0: command not found
I have reverted that change. If you can tested it better also in OSX, it would be great.


Setup os dependent machine config extensions.

- Description of the problem which is fixed/What is the use case
The machine config operator handles RHCOS and FCOS differently when effectuating machine config extensions.
On RHCOS it uses a hardcoded list which is then translated into the actual packages. In our case, sandboxed-containers are translated into kata-containers and then rpm-ostree is called.
On FCOS it just pipes the extensions directly into rpm-ostree, which means that in the current implementation it tries to install sandboxed-containers which doesn't exist in FCOS yum repo.
Fixes #267
- What I did
I added an OS detection mechanism and if it's RHCOS I use sandboxed-containers as extension, otherwise I use kata-containers.
In theory it's unfortunate that it's the OS of the operator that I use for guessing what OS the actual worker node has, but I've never heard of an OCP with FCOS or OKD with RHCOS so I think it's a reasonable assumption.
- How to verify it

Install OKD.
Enable the fcos.repo yum repo
Build from source according to DEVELOPMENT.md.
Install from OKD console.

- Description for the changelog

Support for choosing the right RPM package on OKD/FCOS.

/ok-to-test


make: env: Argument list too long

It looks like we are hitting the ceil of make. Looks like make calls shell with -c and that triggers the error.
An alternative approach would be to eject into into a directory, then we can place multiple files there — Makefile itself, separate shell scripts with env for corresponding packages. I think that also have the advantage of being more observable (it is easier to look into several files of interest rather than go through the 25 KSLOC Makefile).

I like your suggestion. It also seems we'd want this anyways to make the VSCode-style magic sandbox environment loading happen in all the editors. Editors will look for one of these makefiles that are output, and then source them to setup the environment so it can find refmt, ocaml, merlin.


Update framer to 91

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

The latest version remains 9282.


Adding logic to skip Maven if desired

Through the use of the JAVA_ONLY variable, users are now able to choose in install both Java and Maven to complete a full build, or only install Java. This can be useful if the user already has a built artifact they wish to deploy via embedded Jetty or Tomcat server.

I think your use case is better suited to the jvm-common buildpack. You can use this with your app by running:
$ heroku buildpacks:set https://github.com/heroku/heroku-buildpack-jvm-common.git

Also, have you had a look at the heroku-maven-plugin and the Heroku Toolbelt WAR/JAR deployer? Those are the most common tools used for binary deployment.
Let me know if there are reasons those solutions would not work for you.

Thanks @jkutner, the jvm-common buildpack is exactly what I needed. I did some Googling beforehand and couldn't find it. Might be a good idea to mention it somewhere in the README or better yet, have it posted here.


Kong Plugins Annotation Example Doesn't Actually Have An Example

NOTE: GitHub issues are reserved for bug reports only.
For anything else, please join the conversation
in Kong Nation https://discuss.konghq.com/c/kubernetes.

Summary
Attempting to understand how to attach a plugin to a specific service, the readme claims to have an example of how to use annotations to do this but only shows an example of a plugin definition and not an example of using an annotation in an ingress/service definition to attach a plugin to the ingress/service
Kong Ingress controller version
N/A
Kong or Kong Enterprise version
N/A
Kubernetes version
N/A
paste kubectl version output
Environment

Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

What happened
There is no actual example of how to use the plugin CRD
Expected behvaior
Using the kong plugin CRD is confusing and not well documented, there is no example of how to actually attach a plugin to a defined ingress on the kongplugin readme.
Steps To Reproduce

The following link shows new syntax of annotating a KongPlugin object to an ingress/svc:
https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/annotations.md
The following link shows how to annotate a plugin to an ingress/svc using kubectl patch command:
https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/deployment/minikube.md
The following link contains two different examples which use annotating a plugin to an ingress/svc while creating an ingress/svc:
https://github.com/Kong/kubernetes-ingress-controller/tree/master/docs/external-service
Note: the above link still shows the deprecated syntax of plugin annotations, but you do get an idea.

Hello.
I just tested the example it works, but with one change.

Step 2 . Configure a request-transformer plugin to remove the Host header from the original request.

echo "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: transform-request-to-mockbin
config:
remove:
headers: host
" | kubectl create -f -
output
The KongPlugin "transform-request-to-mockbin" is invalid: []: Invalid value: map[string]interface {}{"metadata":map[string]interface {}{"namespace":"default", "generation":1, "creationTimestamp":"2018-11-06T11:47:59Z", "uid":"cef6686c-e1b9-11e8-bd89-080027ada357", "selfLink":"", "clusterName":"", "name":"transform-request-to-mockbin"}, "apiVersion":"configuration.konghq.com/v1", "config":map[string]interface {}{"remove":map[string]interface {}{"headers":"host"}}, "kind":"KongPlugin"}: validation failure list:
.plugin in body is required
I add plugin: request-transformer to be able to work I paste here.
echo "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: transform-request-to-mockbin
config:
remove:
headers: host
plugin: request-transformer
" | kubectl create -f -

Also if you follow the example on creating the Ingress (6. Create an Ingress rule) on the deploy guides (minikube)

Be sure to delele that Ingress so the Expose an external application example works.
Hope it helps!

Thanks to both of you! I was looking in the wrong spot @angelshila and had missed those links, thanks for the tip.
Regardless, I think that plugin spot could use some more information and perhaps a link to those docs, I will consider opening a PR to update it in the future.


Steam Deck not compatible

Just like the issue I have in #197 , when running my game on the steam deck any level that contain Terrain3D won't work.
The game does not crash, it just does not open the scene.
I have Jolt in the project and it runs fine, so I must assume it's not a GDextension issue like the 197 problem on Android.
I'm assuming this is a steam deck problem only, since there are no Linux compatibility errors
Additional info:

SteamOS 3.5
Godot 4.2 dev1
Godot export for Linux, I'm not using Proton to layer windows binaries. I'll try that later tough.
Latest Terrain3D release

Unfortunately it's hard to debug in the deck since there is no official way to run the game on it, apart from using Valve's devkit software to send over the game.

Ok, thanks for the report. You're going to have to do the legwork to test and troubleshoot. That probably means building the plugin so you can tweak code. I can provide upstream support. The latest terrain3d release is only tested on 4.1.1. I have not done any testing on 4.2. Can you get any console to look at logs?
If it doesn't crash and doesn't open the scene, what does it do? Assuming you are running it from a launcher, how does it not open the scene but that's not a crash on startup?
Have you tested the demo?
Are you sure the terrain3d libraries were copied to the device along with the executable?

Ok, thanks for the report. You're going to have to do the legwork to test and troubleshoot. That probably means building the plugin so you can tweak code. I can provide upstream support. The latest terrain3d release is only tested on 4.1.1. I have not done any testing on 4.2. Can you get any console to look at logs?

No problem, I'll get to test it further this week. It works very well for me on 4.2 dev1 - dev5, I only use dev1 because of a problem on another plugin, Nakama, which there were some changes to http requests on dev2 that broke it.

If it doesn't crash and doesn't open the scene, what does it do? Assuming you are running it from a launcher, how does it not open the scene but that's not a crash on startup?

My game opens on a login screen first, then main menu. So only after I select a level with Terrain3D it simply does not load, stays on the menu without crashing.

Have you tested the demo?

Not yet, will do soon.

Are you sure the terrain3d libraries were copied to the device along with the executable?

Yes, made sure they got all sent, and are there.

I built Terrain3D at 3c460256f4b0596785071e72cb3d90a45d55b5a9 on my steamdeck with godot-cpp at 17137b2 and opened the demo project in Godot 4.2.stable and installed godot-jolt v0.11.0-stable into the demo project.
I'm also on Steam OS v3.5.7 and I had to install glibc and linux-api-headers to get it to build in addition to the usual godot dependencies.
The demo runs just fine running it from the editor and exporting it so perhaps the fix for #197 also fixed this issue or something changed in godot, godot-jolt, etc that fixed it.
Let me know if there is anything else I should try now that I have a proper debugging setup on my steamdeck.
Also if anyone is curious, I'm easily getting 200+ fps on the exported demo project on my first generation steamdeck.

Thanks for the report. I'll note it in project status as working in 4.2 and close this.


tests: mcuboot: test_mcuboot: twr_kv58f220m fails

since #78885 enable this on twr_kv58f220m it fails
Describe the bug

What target platform are you using?
twr_kv58f220m
What have you tried to diagnose or workaround this issue?
NA
Is this a regression? If yes, have you been able to "git bisect" it to a
specific commit?
NO

To Reproduce

west build -p always -b twr_kv58f220m --sysbuild tests/boot/test_mcuboot
west flash --runner jlink --erase --tool-opt='-SelectEmuBySN 609302804' --  '--device=MKV58F1M0xxx24'
see error

Expected behavior
mcuboot can boot to test image
Impact
mcuboot function
Logs and console output
*** Using Zephyr OS build v3.7.0-3022-g5942446b9139 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot*** Booting MCUboot v2.1.0-rc1-106-ge890df7ab975 ***
*** Using Zephyr OS build v3.7.0-3022-g5942446b9139 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot*** Booting MCUboot v2.1.0-rc1-106-ge890df7ab975 ***
*** Using Zephyr OS build v3.7.0-3022-g5942446b9139 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot*** Booting MCUboot v2.1.0-rc1-106-ge890df7ab975 ***
*** Using Zephyr OS build v3.7.0-3022-g5942446b9139 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot*** Booting MCUboot v2.1.0-rc1-106-ge890df7ab975 ***
*** Using Zephyr OS build v3.7.0-3022-g5942446b9139 ***
I: Starting bootloader

Environment (please complete the following information):

OS: (e.g. Linux, MacOS, Windows)
Toolchain (e.g Zephyr SDK, ...)
Commit SHA or Version used:  v3.7.0-3022-g5942446b9139

Hi @dkalowsk,
since I don't have the twr_kv58f220m board and it is out of stock,
I'm reassigning back to David and Mahesh.


Not emptying the output when moving the window on different monitor (?workspace)

Version in use:

AUR: hyprland-activewindow 0.4.4-1

STR:

Setup eww bar using active window per each monitor on 2+ monitors (my setup)
Spawn any window with title -> title name is correct
Move the window on different screen -> title name is still displayed for the window that is no longer existing in the workspace

Expected: Title name should be empty when the window is moved to another monitor/workspace
Video 1 (empty workspace)
Video 2 (workspace with other windows)

Ah, I see what the problem is here, thanks for pointing it out.
I really need to refactor the code, so will fix this when I do that. Should have time in the next week or two.

Please try v0.5.0, should be fixed now.


Cannot using keyboard to move to current date when the minDate is set.

Describe the bug
cannot using keyboard to move to current date when the minDate is set.
I see this bug happening on the website as well
https://reactdatepicker.com/
() => {
const [startDate, setStartDate] = useState(new Date());
return (
<DatePicker selected={startDate} minDate={startDate} onChange={date => setStartDate(date)} />
);
};
To Reproduce
Steps to reproduce the behavior:

Go to https://reactdatepicker.com/
Choose the Default example
Add 'minDate={startDate}' to the script
Click on calendar, tab and use arrow key to move to next days
Then you can't go back to the current date. See error

Expected behavior
Should be able to use key <- to move the current date
Desktop (please complete the following information):

OS: MacOS
Browser: Chrome
Version 83.0.4103.116

When selected is set, this issue will be reproduce
() => {   const [startDate, setStartDate] = useState(new Date());   return (     <DatePicker selected={startDate} onChange={date => setStartDate(date)} />   ); };


Add html versions of the invite and signup mails #3134

This commit adds html versions of the invite and signup mails and renames
the existing .txt files to the preferred file extensions '.subject', '.html'
and '.txt'. The html versions of the mails are being sent along with the
text-only versions by the 'send_confirmation' function.
This fixes #3134.

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

Thanks @rishig, added your suggestions.

Merged, thanks @derAnfaenger!


added support for other output file extensions in run.py

After the refactor of v0.2.0 this feature has now been implemented in a new clean branch, to avoid having to avoid merge conflicts.
See: https://github.com/SURFQuantum/yotse/pull/26


[zh] Localize 'continuous_deployment'

[ ] Localize the content/en/continuous_deployment.md to content/zh-cn/ in dev-zh.

Repeated


[Feature/Idea]: I saw you updated GnuCash 5.0 for winget

What would you like to see changed/added?
Now, GnuCash 5.1 is out.  Do you have time to update it as well?  Thanks.

Automation is live now. It will get updated in the next runs.


Please enable CONFIG_SECCOMP (again)

Hi Scaleway,
#158 requested seccomp be enabled and #161 enabled it, but it appears that change was lost somewhere along the line, as many of the kernel configs today do not enable seccomp:
https://github.com/scaleway/kernel-tools/search?p=2&q=CONFIG_SECCOMP&utf8=✓
I work on Sandstorm.io, and we have now received multiple reports from Scaleway users that Sandstorm apps won't start on their servers. It turns out that this is because seccomp is disabled. We have not encountered any other hosting provider nor distro that disables seccomp. We can tell users to use your "Docker" kernel config to get seccomp, but it's not obvious to them in advance that this is required. It seems to me that the best approach would be to enable it across all kernels.
See extended discussion here: https://github.com/sandstorm-io/sandstorm/issues/1759

Hi @kentonv
We have added SECCOMP for the x86_64 kernels, it will be available in the next release 😊

@QuentinPerez thanks for addressing this so quickly! I don't quite understand the turnaround between this fix having been merged and this becoming generally available in the scaleway control panel. Could you elaborate a bit more on when this is expected to be available to end-users? Thanks!

Hi @patrickod,
Here is our process to release new kernels:

add/update .config files and patches if needed on https://github.com/scaleway/kernel-tools
trigger a build on https://github.com/scaleway/qa, example: https://github.com/scaleway/qa/pull/560
Travis builds the new kernel and store it on a temporary store, see https://travis-ci.org/scaleway/qa/builds/123978731 for details
sync the temporary store on our mirrors: http://mirror.scaleway.com/kernel/
create new bootscript in database

There are logs for steps 1-3, using GitHub and Travis, but steps 4 and 5 are manual
However, all the kernels were recently updated with this patch, you can switch to a newer bootscript https://www.scaleway.com/docs/bootscript-and-how-to-use-it/

Which kernels should have this fix? I still can't get Sandstorm working on the 4.5.1 Docker kernel and Ubuntu Wily.

Interestingly enough, the failure mode is now different, and whereas before I got seccomp errors in my logs, now I get nothing other than a silent failure. So the failure to launch Sandstorm might not be related to this issue, but something is definitely very badly broken in unexpected ways. I've never had these issues on a variety of hosting providers. Unfortunately I'm out of time to debug for the day, but the issue can be easily duplicated by installing Sandstorm on a vanilla Ubuntu server, attempting to run an app and watching it fail. The Sandstorm folks have great docs for that process.
Thanks.

Hi @ndarilek,
I installed Sandstrom on our docker image with the kernel 4.5.1 docker, and I have not been able to reproduce your problem
Can you give me more details ?

Hello,
You're right, and I apologize. I've been struggling with this and other
Scaleway issues all day yesterday to perform tasks I assumed would be
easy, and I just assumed this wouldn't work because I'm still having
Sandstorm issues on my original host. I later independently verified
that Sandstorm does indeed work on a new server install, so my existing
issues aren't general ones. Sorry for jumping the gun like that.


Stability: Authenticators

Definition: Authentication requests sent by future stable versions of Parsec should be understood by the same version of the authenticators present on the system.
Enforcement: Unix Peer Crendentials: based on top of stable C standard library APIs. JWT SVID: authentication is based on the SPIFFE Workload API which is a standard and should remain stable.
Enforcement Check
The Unix Peer Credential authenticator is directly used a specific feature of a libc API (getsockopt) and that will remain stable.
The JWT SVID authenticator is based on the SPIFFE Workload API. It seems to be standardised for the X509 part but not sure for the JWT part. We need to make sure it is. The rust-spiffe dependency uses the protobuf definitions at https://github.com/spiffe/go-spiffe/blob/master/proto/spiffe/workload/workload.proto
Testing
The different authenticators should be tested with different versions of the service.

For the JWT-SVID authenticator, see https://github.com/spiffe/spiffe/pull/144. The JWT-SVID profile is going to be integrated into the standard and should become stable henceforth. The current API that we use is the same as in the PR and is not expected to change.
For testing, we should make sure that the authentication work on every PR, but we can also test it with different versions of Parsec, as part as other tests.

The Rust SPIFFE implementation might be remplaced using this crate.
The CI contains multi-tenancy tests which use all authenticators.
In the CI, SPIRE is used for tests as SPIFFE implementation, on a specific version that is fixed.


Call directly functions form Arr and Str

Call directly functions form Arr and Str

Unless you can provide a really good reason as to why I shouldn't use the functions I don't see a point in merging this.

Hey @jasonlewis
The purpose is to avoid unnecessary calls, in the array_* and string_* helper functions case, we call and helper function which is doing nothing but calling the real \Suppor\Arr:: or \Suppor\Str:: function.
If the helper function was doing something on the input or the output, it would make sense.
But in this situation not; it is making things slower (and some might think a bit less OO too)

What sort of overhead are we talking about exactly?

Calls to array_ and str_ helpers functions have been removed in favor of \Suppor\Arr:: or \Suppor\Str:: functions in laravel/framework. The functions are directly called without using the helper function (a function calling another function).
Was it the meaning of your question ?

Calling the function directly makes more sense anyway right, instead of the helper?
Even if the overhead is not that high it still would be less efficient to call the helper which would just call the function anyway?

The only plausable reason to change this imo, would be to avoid potential clashes with other function declarations of the same name. But since this is a laravel specific package, that doesn't apply.
I also think any performance consequences of calling a function that calls a method are negligible, especially given the many micro optimisations that could also be made elsewhere in a php application.
Aside from that I do prefer to use the classes directly though, as it feels a little cleaner. Just my thoughts :)

Both you guys @pulkitjalan and @tymondesigns are right indeed.

I cave.
:wink:


wapiti: init at 3.0.4

Motivation for this change
Wapiti allows you to audit the security of your websites or web applications.
It performs "black-box" scans (it does not study the source code) of the web application by crawling the webpages of the deployed webapp, looking for scripts and forms where it can inject data.
Once it gets the list of URLs, forms and their inputs, Wapiti acts like a fuzzer, injecting payloads to see if a script is vulnerable.
https://wapiti-scanner.github.io/
yaswfp is required. This module was not updated for some time now and this could be a blocker.
Related to #81418
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.


Unusable in React v16+

I'm trying to use this component currently but our app is > v16 and there is currently a crash that renders it unusable.
Element ref was specified as a string (progressBar) but no owner was set. You may have multiple copies of React loaded.
According to this document and a further investigation on my behalf, running npm ls react, this component is creating a new version of react inside the app that causes it to crash.
Would it be possible to fix this?
Thanks

Experiencing the same issue.. it would be helpful to have it fixed. Thanks

@kimmobrunfeldt please update this

+1 Having the same issue.

import React, { Component } from 'react';
import isEqual from 'lodash/isEqual';
import ProgressBar from 'progressbar.js';

class Shape extends Component {
  static defaultProps = {
    ShapeClass: null,
    options: {},
    progress: 0,
    text: null,
    initialAnimate: false,
    containerStyle: {},
    containerClassName: '.progressbar-container',
  };

  shape;

  progressBar = React.createRef();

  create(props, oldProps) {
    if (this.shape) {
      return;
    }

    // setState function is not used to prevent a new render cycle
    // This handling happens outside of React component's lifecycle
    const container = this.progressBar.current;
    this.shape = new props.ShapeClass(container, props.options);
    if (props.initialAnimate) {
      if (oldProps) {
        this.setProgress(oldProps.progress);
      }

      this.animateProgress(props.progress);
    } else {
      this.setProgress(props.progress);
    }

    this.setText(props.text);
  }

  destroy() {
    if (this.shape) {
      this.shape.destroy();
      this.shape = null;
    }
  }

  animateProgress(progress) {
    this.shape.animate(progress);
  }

  setProgress(progress) {
    this.shape.set(progress);
  }

  setText(text) {
    if (text) {
      this.shape.setText(text);
    }
  }

  componentDidUpdate(prevProps) {
    if (!isEqual(this.props.options, prevProps.options)) {
      this.destroy();
      this.create(this.props, prevProps);
    }
    this.animateProgress(this.props.progress);
    this.setText(this.props.text);
  }

  componentDidMount() {
    this.create(this.props, null);
  }

  componentWillUnmount() {
    this.destroy();
  }

  render() {
    const { style, className } = this.props;
    return <div className={className} style={style} ref={this.progressBar} />;
  }
}

class Line extends Component {
  render() {
    return <Shape {...this.props} ShapeClass={ProgressBar.Line} />;
  }
}

class Circle extends Component {
  render() {
    return <Shape {...this.props} ShapeClass={ProgressBar.Circle} />;
  }
}

class SemiCircle extends Component {
  render() {
    return <Shape {...this.props} ShapeClass={ProgressBar.SemiCircle} />;
  }
}

export default {
  Line,
  Circle,
  SemiCircle,
};

Try to force on your package.json the url for this module like:
"react-progressbar.js" : "git+https://github.com/kimmobrunfeldt/react-progressbar.js.git"

you need git installed

run this on your project root folder to update package.json and update the module to the master version
npm i react-progressbar.js@git+https://github.com/kimmobrunfeldt/react-progressbar.js.git --save

A comment that this does not work with React 16+ would be good in the description of this library.


PR template document enhancement

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Since there is a request from developers that the current PR template is not clear when it comes to describe the testbed / reproduction procedure for the bug report, we clarify the ambiguous description in the template.
Type of change
Please delete options that are not relevant.

[x] Documentation enhancement

How Has This Been Tested?
Since this is the documentation improvement about the PR submission, we do believe that it requires any further test to validate its operation.
Checklist:

[ ] 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
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

I'd like to recommend adding a build break check on the checklist.
It will reduce unnecessary efforts if contributors check it before PR.

@suresh-lc PTAL.


Fix a crash when enable a tool plugin uses make_mesh_previews

Fixes #80333
When we update the plugin list, we should check the tree is blocked or not, if blocked, create_item will return nullptr and thus cause crash.

That doesn't look like a good fix. We just end up not updating the list when it is requested because a tree is propagating mouse events. It seems to me that such situation should never arise in the first place, otherwise every tree is potentially error-prone (you either crash or miss an update that you need).
What the solution would look like I'm not sure. For this particular case, though, we should find a way to block make_mesh_previews from running in the same frame as the plugin node is getting ready.

I agree this is not the perfect solution for this, and such situation should never arise in the first place.
But I find it hard to break the chain, Tree::propagate_mouse_event -> EditorNode::add_editor_plugin -> _gdvirtual__ready_call -> make_mesh_previews -> make a progress bar and destruct -> the window receives NOTIFICATION_WM_WINDOW_FOCUS_IN -> call update_plugins .
It seems like delay any of this chain's function to next frame is dangerous and non trivial. make_mesh_previews is in _ready, and user may ask for it's result for later use, not sure how to do it the easy way.

It seems like delay any of this chain's function to next frame is dangerous and non trivial. make_mesh_previews is in _ready, and user may ask for it's result for later use, not sure how to do it the easy way.

That is a problem in and of itself. This method internally moves the main loop two frames ahead. This already can result in unexpected behavior.

Or we can remove the EditorProgress and the following code inside make_mesh_preview
DisplayServer::get_singleton()->process_events();
Main::iteration();
Main::iteration();

The code does look suspicious to me.

We can remove EditorProgress, yeah. It's notorious and we had to do this in past to fix various issues. As a temporary solution this would be more acceptable, I think.
Ideally, make_mesh_preview should probably work asynchronously, just like the resource preview generator does. That would be a breaking compatibility change, but the current implementation is pretty problematic. cc @KoBeWi who's recently worked on make_mesh_preview.

Apply @KoBeWi 's suggestion, godot will complain about “Do not use progress dialog (task) while flushing the message queue or using call_deferred()!”, it seems we still need to remove EditorProgress.

Apply @KoBeWi 's suggestion, godot will complain about “Do not use progress dialog (task) while flushing the message queue or using call_deferred()!”

It does not crash though, so the error is harmless. I'd say the original issue comes from the wrong usage of make_mesh_previews(). We should make sure that the editor does not crash, but errors are fine.

I'd say the original issue comes from the wrong usage of make_mesh_previews().

What do you think about making it asynchronous, like EditorResourcePreview? That should avoid any unexpectedness on the architectural level.

That could work, but it would require a signal for finishing and it's a compatibility breakage (on behavior level).
The Main::iteration() thing caused me some problems in another PR, so I'd be in favor of removing it if it's possible.

Based on your discussion, I guess for this crash we can just add CONNECT_DEFERRED to update_plugins.
Should I remove Main::iteration() too? Why do we have it in the first place, to make the editor progress bar more responsive?

Main::iteration is required to render the meshes. It forces the MainLoop to progress as if a frame has passed.
Removing it would make the deferred flag unnecessary (at least for the purpose of this fix), but it would also require adjusting the make_mesh_previews() behavior.

Thanks!