optimize: optimize metrics

Signed-off-by: slievrly<EMAIL_ADDRESS>

[ ] I have registered the PR changes.

Ⅰ. Describe what this PR did
optimize: optimize metrics
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #4551 (217d2cf) into develop (53d65bf) will increase coverage by 0.13%.
The diff coverage is 82.56%.

@@              Coverage Diff              @@
##             develop    #4551      +/-   ##
=============================================
+ Coverage      49.35%   49.49%   +0.13%
- Complexity      4073     4079       +6
=============================================
  Files            731      732       +1
  Lines          25465    25530      +65
  Branches        3156     3159       +3
=============================================
+ Hits           12569    12635      +66
+ Misses         11559    11550       -9
- Partials        1337     1345       +8

Impacted Files
Coverage Δ

...va/io/seata/core/event/GlobalTransactionEvent.java
0.00% <0.00%> (ø)

...ava/io/seata/server/transaction/saga/SagaCore.java
2.75% <0.00%> (ø)

...in/java/io/seata/server/session/SessionHelper.java
70.37% <60.00%> (-7.16%)
:arrow_down:

...o/seata/server/coordinator/DefaultCoordinator.java
55.39% <75.00%> (+5.39%)
:arrow_up:

...ava/io/seata/server/metrics/MetricsSubscriber.java
85.58% <89.18%> (-2.37%)
:arrow_down:

.../java/io/seata/server/coordinator/DefaultCore.java
54.11% <90.90%> (+0.50%)
:arrow_up:

...java/io/seata/server/metrics/MetricsPublisher.java
93.33% <93.33%> (ø)

...java/io/seata/server/metrics/MeterIdConstants.java
100.00% <100.00%> (ø)

...erver/storage/file/session/FileSessionManager.java
49.01% <0.00%> (-0.66%)
:arrow_down:

... and 3 more


Markdown preview does not auto-update without an open editor

VSCode Version: 1.0.0
OS Version: OSX

Steps to Reproduce:

Open a markdown file and split the window into 1-editor pane and 1-view pane.
Notice that edits made in the editor automatically update the view pane.
Open the file in vim and make edits.
Notice that the edits made in vim automatically update the view pane.
Close the editor pane.
Notice that vim changes no longer update the view pane.

This is because we keep the editor model cached and fail to resolve it from disk when it updates. I would assume when markdown becomes a real extension this issue would also be resolved.

This is still the case with the new extension. There is no model around to be updated.
@kieferrm I think the extension also needs to listen to file changes that happen to the file and do the right thing.

This actually is https://github.com/Microsoft/vscode/issues/20901


Content of the iframe in which the test is currently operating did not load

Are you requesting a feature or reporting a bug?
bug
What is the current behavior?
All the test cases which are switching to a frame fail with the error: "Content of the iframe in which the test is currently operating did not load"
Tested page URL: https://elk.co/
Minimum code to reproduce the issue:
import { Selector } from 'testcafe';
import utils 		from '../utils.js';
fixture To test frame load failiares
.page('https://elk.co?loglevel=debug');
test('Valid user credentials creation', async (t) => {
await t
.click(Selector('.loggedOut > a:nth-child(1)'))
.expect(Selector('.username')).ok({ timeout: 5000 })
.typeText(Selector('.username'), 'smoke-' + utils.timestamp)
.typeText(Selector('.email'<EMAIL_ADDRESS>.typeText(Selector('.password'), 'T9e5s1t7P')
.expect(Selector('.continueBtn').exists).ok({ timeout: 5000 })
.click(Selector('.continueBtn'))
.expect(Selector('#Content')).ok({ timeout: 6000 })
.switchToIframe(Selector('#Content'), { timeout: 7000 })
.setPageLoadTimeout(45000)
.expect(Selector('.tooltip-wrapper').exists).ok({ timeout: 15000 });
});
Specify your

operating system: MacOS High Sierra version 10.13.4
testcafe version: 19.2
node.js version: any

Notes: Visually while test cases are executed I can see that the content of the frames is actually loaded, but it fails all the time with the error indicated above. Also no timeouts or waits will help, I tried to set a very long timeouts and it fails anyway with the same error.

Duplicate of https://github.com/DevExpress/testcafe/issues/2387

The problem does not relate to iframes.
We don't correctly check a same-origin policy for second-level domains web.elk.co and app.elk.co.
It's a general restriction of our web-proxy. I've created a separate issue in its repository - https://github.com/DevExpress/testcafe-hammerhead/issues/1787.
As a temporary workaround, try to run Google Chrome with the --disable-web-security flag.


Permission denied error when starting Gitea after updating to 1.17.0

Description
I have updated to Gitea 1.17.0, but when starting it I receive an error in the console, and then it exits. The message is available in the first file of my log gist.
In the docker compose file I have 2 volumes defined for use directly by Gitea:

/mnt/gitea/data/ - /var/lib/gitea
/mnt/gitea/custom - /etc/gitea

Gitea should run under user 1000, as set up in the docker compose file:
environment:
    - USER_UID=1000
    - USER_GID=1000

According to the console log, Gitea tries to create the /var/lib/gitea/custom/home directory, which is mapped to /mnt/gitea/data/custom/home on the host system.
After inspecting this latter path, I see that no one is granted write permissions on the custom directory in it:
/mnt/gitea/data $ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
dr-x------ 13 1000 1000 4.0K nov   10  2021 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

However, if I grant write permission to the owner with sudo chmod u+w custom, Gitea will still produce the same error on startup, then exit, and when exited, the write permission on the directory have disappeared.
I suspect that Gitea is unable to create the new home directory because it removes the write permission from it's parent directory, but I also suspect that I might be doing something wrong, as no one else has reported this bug yet.
If I try to fix this problem by hand, by manually creating the directory and setting ownership, as seen here:
sudo mkdir custom/home
sudo chown 1000:1000 custom/home

then starting up Gitea can continue a little, but will exit again because it wants yet another directory besides the new home one. The output from this run is in the second file in my log gist.
Gitea Version
v1.17.0
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/mpeter50/c7ba7eb7fc5e74fd708736736800a4e6
Screenshots
No response
Git Version
2.36.2
Operating System
Raspbian
How are you running Gitea?
I'm running Gitea in Docker, for which I have built the container image myself, using the Docker.rootless DOckerfile in the repo.
Database
MySQL

For the time being, I have reverted to 1.16.5, and it seems to run as expected.

Set [git].HOME_PATH to an appropriate place for your configuration in app.ini.
See the breaking changes notices in our blog post: https://blog.gitea.io/2022/07/gitea-1.17.0-is-released/#-internal-gitconfig-19732httpsgithubcomgo-giteagiteapull19732
Copied below:
Internal Gitconfig (#19732)
Previously, Gitea used the users gitconfig ($HOME/.gitconfig) in addition to the system gitconfig (/etc/gitconfig).
Now, Gitea uses the system gitconfig (/etc/gitconfig) combined with an internal gitconfig located in {[git].HOME_PATH}/.gitconfig. If you customized your user gitconfig for Gitea, you should add these customizations to one of the available gitconfigs. Additional git-relevant files that are normally in your user home directory, like $HOME/.gnupg, should be moved/ copied to {[git].HOME_PATH}/ as well.

Thank you for the information.
I've read the mentioned breaking change notices, and I haven't modified the gitconfig of the user that runs Gitea.
On the other hand, maybe I misunderstand something, but why should I override the git home path?
The current path is fine to me, and even more, I prefer it to be in the original location. The problem is that Gitea is unable to create this new directory, because it does not have permission to do so. I think this might be caused by Gitea trying to fix the permissions of its own directory, but does it wrongly, and it gets in its own way.

The error you're receiving is stating it can't create what is the new default [git].HOME_PATH so I suggest you override this.

The error you're receiving is stating it can't create what is the new default

I understand, but is that expected behavior? Is this specific to the Docker environment? I'm asking because you have defined that path as the default for a reason.
As far as I'm aware I did not do anything to harden the filesystem permissions of Gitea directories, but Gitea itself does that, and in doing so it breaks itself. If this is the case, I think this is a bug.

I changed nothing to any ssh configs but the 1.17 update still breaks my SSH.

What is the output of docker info?

$ sudo docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.1-docker)

Server:
 Containers: 9
  Running: 9
  Paused: 0
  Stopped: 0
 Images: 27
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.103-v7l+
 Operating System: Raspbian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: armv7l
 CPUs: 4
 Total Memory: 1.87GiB
 Name: rpi
 ID: 3KSL:X4E5:RLEW:IP66:X6LR:CN5Z:Z7PV:DNNB:5TQF:KIPY:UMWV:AXXV
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support

The [git] HOME_PATH is a new setting from 1.17.
It defaults to APP_DATA_PATH/home. Where [server] APP_DATA_PATH is /data/gitea in the docker and thus /data/gitea/home
Simply create the directory /data/gitea/home on the docker and give Gitea permission to write to that directory.

It defaults to APP_DATA_PATH/home. Where [server] APP_DATA_PATH is /data/gitea in the docker and thus /data/gitea/home

In my configuration file [server] APP_DATA_PATH has the value /var/lib/gitea/custom.
I don't remember customizing this value, and according to the compose snippet in the Docker Rootless installation document, most of Gitea data is stored in the parent of this directory, so probably this was the default for Docker, at least when I started using Gitea.
I also don't have a /data directory in the container:
$ sudo docker exec -it gitea bash
bash-5.1$ ls -a /
.           ..          .dockerenv  app         bin         dev         etc         home        lib         media       mnt         opt         proc        root        run         sbin        srv         sys         tmp         usr         var
bash-5.1$ ls -a /var/lib/gitea
.       ..      custom  git     ssh

I haven't customized the value of [git] HOME_PATH (I don't have a git section), so this means it should point to APP_DATA_PATH/home, which is /var/lib/gitea/custom/home in my case.
According to the second parapgraph in this document. Gitea should try to create the directories it needs, including this one. That is fine because it actually tries to create the directory at /var/lib/gitea/custom/home, but it fails, because it does not have write permissions on the directory /var/lib/gitea/custom:
$ sudo docker exec -it gitea bash
bash-5.1$ ls -hal /var/lib/gitea/custom
total 52K
dr-x------   13 git      git         4.0K Jul 31 18:34 .
drwxr-xr-x    5 git      git         4.0K Oct 29  2021 ..
drwxr-xr-x   19 git      git         4.0K Nov 12  2021 attachments
drwxr-xr-x    3 git      git         4.0K Sep 20  2021 avatars
drwxr-xr-x    2 git      git         4.0K Jul 31 11:31 conf
drwxr-xr-x    4 git      git         4.0K Jun 14  2021 indexers
drwxr-xr-x    2 git      git         4.0K Oct 22  2021 jwt
drwxr-xr-x    2 git      git         4.0K Jun 13  2021 log
drwxr-xr-x    8 git      git         4.0K Oct 22  2021 queues
drwxr-xr-x    2 git      git         4.0K Oct 22  2021 repo-archive
drwxr-xr-x    2 git      git         4.0K Jun 14  2021 repo-avatars
drwx------   18 git      git         4.0K May 24 20:11 sessions
drwxr-xr-x    3 git      git         4.0K Aug  1 23:50 tmp

As you may see, the permissions for the directory is only reading and execution for the git user.
I haven't modified the permissions, except trying to give the owner of the /var/lib/gitea/custom directory write permissions to it, but that was reverted as soon as Gitea started, and it still wasn't able to create the directories that it wanted.

Simply create the directory /data/gitea/home on the docker and give Gitea permission to write to that directory.

I don't have a /data directory, but if I try to create /var/lib/gitea/custom/home:

I need to use sudo, because otherwise I don't have permissions
I will just shift the problem a little bit: next I'll also need to create the packages directory, and who knows how much more, because Gitea won't be able to create that either

I installed gitea 1.70 using sudo snap install gitea on Ubuntu 22.04 LTS, it doesn't automatically create /etc/gitea/app.ini.
I create a user called gitea and set its home directory to /var/lib/gitea , and execute sudo mkdir /var/lib/gitea && sudo chown gitee: /var/lib/gitea to modify permission.
The /etc/systemd/system/gitea.service is:
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
Wants=mysql.service
After=mysql.service

[Service]
RestartSec=2s
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea/
RuntimeDirectory=gitea
ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=gitea HOME=/var/lib/gitea/ GITEA_WORK_DIR=/var/lib/gitea

[Install]
WantedBy=multi-user.target

When I set the Repository Root Path to /var/lib/gitea/common/data/gitea-repositories and Run As Username to gitea on the initial configuration page, it cannot be installed successfully, and it prompts The repository root path is invalid: mkdir / var/lib/gitea: read-only file system.
I don't know what [git].HOME_PATH is or where it is, because it doesn't have a default configuration file nor is it detailed in the installation process.
I think if [git].HOME_PATH is mandatory, then it should have a default configuration, or specify it before startup as an environment variable. This configuration confuses people.

I am receiving the same error. I have the following mount:
- /home/git/.gitconfig:/data/gitea/home/.gitconfig

and I have set the following env definitions
GITEA__git__HOME_PATH=/data/gitea/home
USER_UID=116
USER_GID=123

and the file .gitconfig has the following permissions
$ sudo -u git ls -ln /home/git/.gitconfig
-rw-rw-r-- 1 116 123 1 Aug 16 21:57 /home/git/.gitconfig

however, when starting up the container, I receive this error:
- error: could not lock config file /data/gitea/home/.gitconfig: Permission denied

I understand that the user whose UID/GID is defined in the environment is the one performing the operations and, as stated in the ls command, said user can read/write the .gitconfig file. Am I missing something here?

I made a fresh install on 1.17, which worked for a while. But now it is having the exact same problem as before, with permission errors when it tries to read the SSH key despite its permissions being correct as we established while troubleshooting the issue on Discord. I think 1.17 is flawed

@swang-harbin I don't know how to install Gitea that way, but some things I wanted to let you know:

[...] and it prompts The repository root path is invalid: mkdir / var/lib/gitea: read-only file system.

This looks like a path specification problem. I'm not sure where did you set "Repository Root Path", but looking at the error message it looks the first / has been separated somehow from the rest of the path. Also, I think paths (and other strings) contain characters that need to be escaped if used in systemd unit files; in turn maybe your "Repository Root Path" is ok, and you need to fix the paths in the Environment line and other lines of your unit file that you inserted in your comment. Please check the systemd unit file specification for that.

I don't know what [git].HOME_PATH is or where it is, because it doesn't have a default configuration file nor is it detailed in the installation process.

There is the gitea.ini file (somewhere) that Gitea uses. It is mostly a traditional ini file.
The mentioned "path" refers to a HOME_PATH setting under the [git] section. If you want to customize it, it should look like this in the said file:
[git]
HOME_PATH=/your/path/goes/here

Other settings and other sections can be before and after this excerpt, and this section can also contain other settings, but I think you should only define the [git] section once, so it shouldn't appear more than once.
BUT, you don't have to do anything with this setting, or the [git] section, if you are fine with the default configuration, as by default this setting has the value of <TODO: find it's value, insert here>.
@c4tich

I am receiving the same error.

however, when starting up the container, I receive this error:
- error: could not lock config file /data/gitea/home/.gitconfig: Permission denied

I think that is a different error, but it might have some similarities.
Does the git user have the UID of 116, or is it in the group of GID 123?

@techknowlogick @zeripath I feel my issue is ignored.
To recap what has happened so far:
I have introduced my problem: Gitea is changing filesystem permissions so that it gets in its own way, and in turn it cannot create the new directories used for the new features of 1.17.
You recommended to change a setting permanently (store a few directories elsewhere), to work around the issue.
I didn't accept that, because it does not solve the actual problem, but creates more on the topic of maintenance.
The reason I didn't accept the workaround to set a different directory for the git home directory, is that my Gitea instance uses the default storage path configurations, and yet it mismanages the directory where it stores all its data.
Gitea has total authority of the data directory it uses (by default), and yet it cannot create its subdirectory there.
If I try to fix the permissions so that Gitea can create its own new subdirectories, it reverts the changes before it would do anything else, including creating the new subdirectories.

"Repository Root Path" and "Run As Username" are both on the Initial Configuration page for port 3000：

)
And the access permissions of the /var/lib/gitea directory are：
$ ll -d /var/lib/gitea
drwxr-xr-x 5 gitea gitea 4096 Aug 16 04:41 /var/lib/gitea/

And systemd unit file copied from here
I found instructions for [git].HOME here, but it still gives the same error after I configure APP_DATA_PATH=/var/lib/gitea in the Environment in the systemd unit file
At the same time, after I set Environment to Environment="Environment="USER=gitea HOME=/var/lib/gitea/ GITEA_WORK_DIR=/var/lib/gitea/" or  Environment="Environment="USER=gitea HOME=/var/lib/gitea/ GITEA_WORK_DIR=/var/lib/gitea/ APP_DATA_PATH=/var/lib/gitea", it still gives the same error

Could you run ./gitea doctor to check if there is any error hints?

There are many different voices here and some are caused by different problems.
IMO most of the problems are not related to Gitea itself, but related to the environment.
I will provide a summary for various "permission" problems:

Make sure your Gitea is running with the correct Linux user (uid). You can check a user's uid by command id the-user-name. And you can google (ps show uid/username) to learn how to know a process's uid or username (eg: ps aux)
Make sure your filesystem has the correct uid/username as the Gitea process
Make sure there is no other program changing the uid on your filesystem
If you are using systemd, setting Environment="USER=gitea is incorrect. You can google about "systemd set user" to learn how to set a service's user correctly (eg: User=xxx, do not put it in the Environment)
If you are using Docker, make sure the UID/GID mapping is correct inside the container, ie: you should make sure the ps aux show the same user as the the ls -l inside the container.
OpenSSH also requires that the .ssh and related directories/files have the correct permission, otherwise OpenSSH won't start or work (also not related to Gitea directly)

In short, in most cases permission problems are related to the environment, understand your environment and tune the permissions carefully.

@swang-harbin
If you see The repository root path is invalid: mkdir /var/lib/gitea: read-only file system., please use sudo to switch your command line user to gitea to test if you can do something like mkdir /var/lib/gitea/test-dir. It's highly likely your filesystem can not be written correctly.
Or, you could try to use another directory for Gitea, eg: mkdir /data/gitea; chown ... /data/gitea then use it.

@lunny
I run gitea doctor,and it prints the error below
$ gitea doctor
panic: Failed to create sublogger (doctor): open doctor.log: permission denied

goroutine 1 [running]:
code.gitea.io/gitea/modules/log.NewLogger(0x2a69fb5?, {0x2848a7e?, 0xc00221e728?}, {0x282bb70?, 0x1?}, {0xc00016d400?, 0x45ff69?})
        /build/gitea/parts/gitea/build/modules/log/log.go:49 +0x105
code.gitea.io/gitea/cmd.runDoctor(0xc000181080)
        /build/gitea/parts/gitea/build/cmd/doctor.go:152 +0x27e
github.com/urfave/cli.HandleAction({0x24010c0?, 0x36320a0?}, 0xc000eda1c0?)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/app.go:524 +0xa8
github.com/urfave/cli.(*App).RunAsSubcommand(0xc000eda1c0, 0xc000180f20)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/app.go:410 +0x831
github.com/urfave/cli.Command.startApp({{0x2848a7e, 0x6}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x294371f, 0x11}, {0x0, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/command.go:372 +0x6e7
github.com/urfave/cli.Command.Run({{0x2848a7e, 0x6}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x294371f, 0x11}, {0x0, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/command.go:102 +0x808
github.com/urfave/cli.(*App).Run(0xc000eda000, {0xc000134000, 0x2, 0x2})
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/app.go:277 +0x8a7
main.main()
        /build/gitea/parts/gitea/build/main.go:115 +0xcf9

@wxiaoguang
I see from here that some environment variables need to be specified at runtime, so I use USER=gitea USERNAME=gitea HOME=/home/gitea/ GITEA_WORK_DIR=/home/gitea/ gitea web to start, but its print information is still start with /var/snap/gitea
gitea@xx:~$ USER=gitea USERNAME=gitea HOME=/home/gitea/ GITEA_WORK_DIR=/home/gitea/ gitea web
2022/08/18 05:06:09 cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 119245
2022/08/18 05:06:09 ...s/install/setting.go:21:PreloadSettings() [I] AppPath: /snap/gitea/6058/gitea
2022/08/18 05:06:09 ...s/install/setting.go:22:PreloadSettings() [I] AppWorkPath: /var/snap/gitea/common
2022/08/18 05:06:09 ...s/install/setting.go:23:PreloadSettings() [I] Custom path: /var/snap/gitea/common
2022/08/18 05:06:09 ...s/install/setting.go:24:PreloadSettings() [I] Log path: /var/snap/gitea/common/log
2022/08/18 05:06:09 ...s/install/setting.go:25:PreloadSettings() [I] Configuration file: /var/snap/gitea/common/conf/app.ini
2022/08/18 05:06:09 ...s/install/setting.go:26:PreloadSettings() [I] Prepare to run install page
2022/08/18 05:06:10 ...s/install/setting.go:29:PreloadSettings() [I] SQLite3 is supported
2022/08/18 05:06:11 cmd/web.go:208:listen() [I] Listen: http://<IP_ADDRESS>:3000
2022/08/18 05:06:11 cmd/web.go:212:listen() [I] AppURL(ROOT_URL): http://localhost:3000/
2022/08/18 05:06:11 ...s/graceful/server.go:61:NewServer() [I] Starting new Web server: tcp:<IP_ADDRESS>:3000 on PID: 119245

It can launch the configuration page.I use its default repository root path: /var/snap/gitea/common/data/gitea-repositories,its error message becomes: Failed to save configuration: mkdir /var/snap/gitea/common/conf: permission denied.If I change /var/snap/gitea/common/data/gitea-repositories to /home/gitea/common/data/gitea-repositories, it gives: The repository root path is invalid: mkdir /home/gitea/common: permission denied.
I think this error may be because I installed using snap, maybe I should use docker.

@lunny I run gitea doctor,and it prints the error below
$ gitea doctor
panic: Failed to create sublogger (doctor): open doctor.log: permission denied

goroutine 1 [running]:
code.gitea.io/gitea/modules/log.NewLogger(0x2a69fb5?, {0x2848a7e?, 0xc00221e728?}, {0x282bb70?, 0x1?}, {0xc00016d400?, 0x45ff69?})
        /build/gitea/parts/gitea/build/modules/log/log.go:49 +0x105
code.gitea.io/gitea/cmd.runDoctor(0xc000181080)
        /build/gitea/parts/gitea/build/cmd/doctor.go:152 +0x27e
github.com/urfave/cli.HandleAction({0x24010c0?, 0x36320a0?}, 0xc000eda1c0?)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/app.go:524 +0xa8
github.com/urfave/cli.(*App).RunAsSubcommand(0xc000eda1c0, 0xc000180f20)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/app.go:410 +0x831
github.com/urfave/cli.Command.startApp({{0x2848a7e, 0x6}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x294371f, 0x11}, {0x0, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/command.go:372 +0x6e7
github.com/urfave/cli.Command.Run({{0x2848a7e, 0x6}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x294371f, 0x11}, {0x0, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/command.go:102 +0x808
github.com/urfave/cli.(*App).Run(0xc000eda000, {0xc000134000, 0x2, 0x2})
        /root/go/pkg/mod/github.com/urfave/cli@v1.22.5/app.go:277 +0x8a7
main.main()
        /build/gitea/parts/gitea/build/main.go:115 +0xcf9

Looks like your current user have no write permissions to the log directory.

@lunny

Could you run ./gitea doctor to check if there is any error hints?

Do you say this to me or to swang-harbin?
If to me, is it ok to try that in my Gitea 1.16.5 container, or should I use the 1.17.0 container to execute this command?

@wxiaoguang

Make sure your Gitea is running with the correct Linux user (uid).
Make sure your filesystem has the correct uid/username as the Gitea process

I have ran the following commands inside the Gitea container, while it is running with version 1.16.5:
# docker exec -it gitea bash
bash-5.1$ id git
uid=1000(git) gid=1000(git) groups=1000(git),1000(git)
bash-5.1$
bash-5.1$ ps aux | grep gitea
    1 git       8h14 /usr/local/bin/gitea -c /etc/gitea/app.ini web
27406 git       0:00 grep gitea
bash-5.1$
bash-5.1$ ls -hal /var/lib/gitea
total 20K
drwxr-xr-x    5 git      git         4.0K Oct 29  2021 .
drwxr-xr-x    1 root     root        4.0K Mar 24 11:49 ..
dr-x------   13 git      git         4.0K Jul 31 18:34 custom
drwx------    5 git      git         4.0K Mar 26 00:21 git
drwx------    2 root     root        4.0K Jun 13  2021 ssh
bash-5.1$
bash-5.1$ stat -c "%u %g" /proc/1
1000 1000
bash-5.1$ stat -c "%u %g" /var/lib/gitea
1000 1000
bash-5.1$ stat -c "%u %g" /var/lib/gitea/custom/
1000 1000

ps cannot print the UID of processes as it seems the busybox of the container has a minimal version of it, so I used stat instead.

Make sure there is no other program changing the uid on your filesystem (for example, some incorrect backup/restore program will break the permissions)

I currently don't have any program that manages backups or similar tasks.
If you want, I may try to install the audit tools on this system and set up detection for file permission changes to see what actually makes the changes. Or rather in the container, probably that would make more sense.

If you are using systemd [...]

I do, but it is only involved in starting the Docker daemon. The containers are managed by docker-compose.

If you are using Docker, make sure the UID/GID mapping is correct inside the container, ie: you should make sure the ps aux show the same user as the the ls -l inside the container. In some cases there could be a docker (rare) bug that makes the permissions messy.

Do you mean that both of the mentioned commands need to be run in the container?
If so, the user names are matching.

OpenSSH also requires that the .ssh and related directories/files have the correct permission, otherwise OpenSSH won't start or work (also not related to Gitea directly)

Thanks for letting me know, the ownership of that directory was weird to me too, but didn't know what it should be. I'll let it alone for now, as I don't use it, and I think that feature has been removed from 1.17 anyway.

In short, in most cases permission problems are related to the environment, understand your environment and tune the permissions carefully (maybe in the future Gitea can provide a tool to help to check the environment)

In my opinion I have already tried to tune the permissions carefully, but my tunings were reverted as soon as I started the Gitea container.

If you believe there is a bug, please report: What's the username and uid are for Gitea process, what are the filesystem permissions(owner/mod) for the Gitea's custom/data and related directories/files. If you are running Gitea with docker, please collect these information inside the docker container.

I have included these near the top of this comment, in my response to your first and second points.

@mpeter50 This issue has became very long, I am not sure whether your problem has been resolved.
My first thought about your original problem is that the custom directory didn't have correct mode, it was dr-x------ , it's not writable, then it couldn't be written by Gitea correctly. Gitea expects that the custom directory should be writable. And during the startup, Gitea may create directories under the custom directory automatically.
Maybe you could do sudo chmod 0700 custom to fix the problem.

but my tunings were reverted as soon as I started the Gitea container.

What are reverted? If you mean that you can not make the custom directory writable, then it's highly likely caused by Docker's UID/GID mapping behavior (another long story, especially for users with CIFS/SMB/Windows storage).

@swang-harbin:

I run gitea doctor,and it prints the error below
$ gitea doctor
panic: Failed to create sublogger (doctor): open doctor.log: permission denied
...

Whilst the error message is very unfriendly and should be fixed, you should read it and then think a bit more instead of throwing your hands up.
What is the problem?
The doctor command is panicking with Failed to create sublogger (doctor): open doctor.log: permission denied
What does that mean?
The doctor command cannot write to doctor.log in its current directory
How can this be solved?

Switch to a user who can write to doctor.log in the current directory
Consider if there is a way to change where the doctor command will write its logs.

Can the doctor command change where it logs?
Look at the help sheet for the command online or by running:
$ gitea doctor --help

What does that say?
NAME:
   Gitea doctor - A command to diagnose problems with the current Gitea instance according to the given configuration. Some problems can optionally be fixed by modifying the database or data storage.

...

   --log-file value               Name of the log file (default: "doctor.log"). Set to "-" to output to stdout, set to "" to disable

...

So how can I change the log file location?
Add the --log-file "-" option to the command e.g.:
gitea doctor --log-file "-"  --all

@wxiaoguang

@mpeter50 This issue has became very long, I am not sure whether your problem has been resolved.

I agree, multiple people have been replying with different problems. My issue has not been resolved, I'm still running 1.16.5, and I would like to update to 1.17.

My first thought about your original problem is that the custom directory didn't have correct mode, it was dr-x------ , it's not writable, then it couldn't be written by Gitea correctly. Gitea expects that the custom directory should be writable. And during the startup, Gitea may create directories under the custom directory automatically.

Yes, I understand that.
I have tried to manually add write permissions for the owner of the folder with chmod, but as soon as I start the Gitea container, the write permission gets revoked for some reason.

What are reverted? If you mean that you can not make the custom directory writable, then it's highly likely caused by Docker's UID/GID mapping behavior (another long story, especially for users with CIFS/SMB/Windows storage).

I meant this, yes. The permissions of the custom directory get changed from drwx------ to dr-x------.
I don't use network storage for any directories of Gitea, everything is stored on the root partition of the host system, which is a USB connected portable hard drive.
I'll try to look up this UID/GID remapping behavior, though could you please give me soime pointers? An article would do. I request this to make sure we are on the same page.

If you mean this feature of Docker, I have been using it for something else earlier, but I don't use it for Gitea.
To make sure that this is how it is actually, inside the container I see the same UIDs as the owner of the custom, git and ssh directories, as I see outside of the container, looking at my docker volumes:
Inside the container:
bash-5.1$ ls -haln /var/lib/gitea/
total 20K
drwxr-xr-x    5 1000     1000        4.0K Oct 29  2021 .
drwxr-xr-x    1 0        0           4.0K Mar 24 11:49 ..
dr-x------   13 1000     1000        4.0K Jul 31 18:34 custom
drwx------    5 1000     1000        4.0K Mar 26 00:21 git
drwx------    2 0        0           4.0K Jun 13  2021 ssh

On the host system:
ls -haln /mnt/gitea/data/
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5    0    0 4.0K jún   14  2021 ..
dr-x------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2    0    0 4.0K jún   13  2021 ssh

The relevant volume mapping in the docker-compose file:
[...]
volumes:
    gitea_data:
        driver: local
        driver_opts:
            type: none
            o: bind
            device: /mnt/gitea/data/
[...]
services:
    server:
        image: local/gitea/gitea:${GITEA_VERSION}
        container_name: gitea
        [...]
        volumes:
            - gitea_data:/var/lib/gitea
[...]

It really depends a lot of facts. Docker has root and rootless version. There doesn't seem to be an official document for it, I just searched and tried by myself before. So, the following information may not be accurate, just for your information.
For docker-with-root, the UID/GID/mode are stored with the file on the file system. I guess you are using the docker-with-root image. For docker-rootless, the UID/GID/mode are stored with xattr or NTFS extended attribute. Docker for Windows has more complex behaviors, depending on which backend is used (WSL2 or not), it's off-topic for this problem.
In my environment, the directories looks like this:
drwxr-xr-x  5 1000 1000 4.0K Aug 21  2021 git
drwxr-xr-x 17 1000 1000 4.0K Jul  8 16:47 gitea
drwx------  2 0    0    4.0K Aug  9  2021 ssh

Then the question is, why your custom directory always has the dr-x------ mode.
I think there could be some tests to try (if you have time ...)

Stop the Gitea container
Manually chmod 0700 custom to see whether the mode can be changed. If no, then that's the root problem (filesystem).
If the mode can be changed, then mount it to a simple container and start, exec into the shell to see whether the mode is correct. If no, then that's the root problem (docker).
If the custom inside the simple container is correct, then stop the container to see whether the mode is still correct on the host.
If everything is still correct, then mount the custom to the production Gitea container and start. If the mode becomes incorrect again, then it's the Gitea docker image or program problem.

@wxiaoguang thanks, I'll try these tests soon.

Oh, one question. I should do the with-Gitea parts of the test with the 1.17 image, right?

You could try it with 1.16.x first to see whether the behavior differs, in case it's a regression bug for 1.17? 😂

If you only has 1.17 database, only 1.17 is also fine, at least we can know the problem

@mpeter50 regarding to the question you asked me, yes, git user's UID is 116 and GID is 123
cut -d ':' -f1-4 /etc/passwd | grep git
git:x:116:123

The tests are done, here are the results.
Docker bug test
First I checked if just mounting to a docker container changes the permissions.
I gave write permissions to the owner on the custom directory:
$ sudo chmod u+w custom/
$ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
drwx------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

I started the container with this command:
sudo docker run -it --volume 'gitea_gitea_data:/mnt/gitea_data' debian bash

(gitea_gitea_data is a named volume stored at the location where I executed the previous commands)
Checked the permissions inside too, and stopped the container:
# cd /mnt/gitea_data/
# ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K Oct 29  2021 .
drwxr-xr-x  1 root root 4.0K Aug 19 07:27 ..
drwx------ 13 1000 1000 4.0K Jul 31 16:34 custom
drwx------  5 1000 1000 4.0K Mar 25 23:21 git
drwx------  2 root root 4.0K Jun 13  2021 ssh
# exit

Checked the permissions outside again:
$ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
drwx------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

Gitea bug test
Out of curiosity first I tried with the current container (1.16.5).
I checked if the permissions are still ok, before starting the container:
$ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
drwx------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

I started the container with docker-compose (if you're interested in the compose file, please let me know):
sudo docker-compose up

After the database and Gitea has finished starting up (~1 minute), I checked the permissions again:
$ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
dr-x------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

The permissions have changed.
I also checked inside the container:
$ sudo docker exec -it gitea bash
bash-5.1$ ls -hal /var/lib/gitea/
total 20K
drwxr-xr-x    5 git      git         4.0K Oct 29  2021 .
drwxr-xr-x    1 root     root        4.0K Mar 24 11:49 ..
dr-x------   13 git      git         4.0K Jul 31 18:34 custom
drwx------    5 git      git         4.0K Mar 26 00:21 git
drwx------    2 root     root        4.0K Jun 13  2021 ssh

I also checked this again with 1.17.0.
I set the write permission again:
$ sudo chmod u+w custom/
$ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
drwx------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

I changed the container image to start, and started the container:
sudo docker-compose up

When Gitea has started to start up and printed its first error messages, the permissions were changed again:
$ ls -hal
total 20K
drwxr-xr-x  5 1000 1000 4.0K okt   29  2021 .
drwxr-xr-x  5 root root 4.0K jún   14  2021 ..
dr-x------ 13 1000 1000 4.0K júl   31 18:34 custom
drwx------  5 1000 1000 4.0K márc  26 00:21 git
drwx------  2 root root 4.0K jún   13  2021 ssh

Conclusion
The strange behavior is connected to the Gitea container, but it looks it hasn't been introduced with 1.17.0, as the 1.16.5 container does this too.

search all codebase with os.MakeDir and os.MakeDirAll, couldn't find 500 permission. It's confusing.

search all codebase with os.MakeDir and os.MakeDirAll, couldn't find 500 permission. It's confusing.

In most cases, Gitea uses 0o777 + umask for the mode.

@mpeter50 Have you ever set some umask related things?
I can reproduce the behavior by:
func main() {
	syscall.Umask(0o277)
	os.MkdirAll("/tmp/test-dir/test", 0o755)
}
// then you will get:
// dr-x------ 2 uid gid  64 Aug 19 16:10 test-dir/

@mpeter50 Have you ever set some umask related things?

On the host OS I have the umask set to 022:
$ umask
0022

The container has this too: (for being able to execute this command, I started 1.16.5)
sudo docker exec -it gitea bash
bash-5.1$ umask
0022

The directory where I store the data files of Gitea is stored on the root partition, and according to /etc/fstab it is mounted with defaults,noatime options, or rw,noatime according to mount (/dev/sda2 on / type ext4 (rw,noatime)).
Otherwise I don't remember touching the umask setting on this system.

Thank you for your time, I think I know the problem now.
I found this:
https://github.com/go-gitea/gitea/blob/main/docker/rootless/usr/local/bin/docker-setup.sh#L8
mkdir -p ${GITEA_CUSTOM} && chmod 0500 ${GITEA_CUSTOM}

😂

I proposed a PR for it:

#20861

But I haven't fully understand the problem at the moment.

Today I updated my instance to version 1.17.2, and everything seems fine.
Thanks again for looking into this!


GPII-3968: Updated to new enough version to pick up payload validation checks.

This is the second pull to add validation checks to various endpoints provided by the universal repository.
This is the second pull, the previous pull did not use a new enough version of the universal docker container.
This deployment does not require any special handling, there are no changes to data stored in CouchDB that would require a migration.  There are  no new containers, i.e. this is. just an update to the three containers provisioned from the universal container.
@cindyli can easily verify the change by:

Logging in to get auth credentials.
Using those credentials to attempt to submit an invalid payload to one of the secured endpoints, (settings GET, etc.).

lgtm


Upload Brianex Token

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

[x] Filename in the lowercase format
[x] Image format: png
[x] Image size: 256 by 256 px

I have added lowercased version here https://github.com/TrustWallet/tokens/commit/f2ecea912d01fdd8e0d813b9ac2e0c54b6a14067
Also, you can use these graphics to say that your ERC20 token fully compatible with Trust Wallet (https://trustwalletapp.com/logo-assets). Tokens will show up automatically once the user receives them.
Feel free to share this on social media and tag Trust Wallet:

Twitter: @trustwalletapp

Facebook: @trustwalletapp

Thanks For your help
i think error from image,but just filename


Read from free memory in btDiscreteDynamicsWorld::removeConstraint(btTypedConstraint*)

Godot version:
3.2.dev.custom_build. 3ea33c0e4
Issue description:
It happens when Rigidbody exists with joint in one scene
==10385==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000000b10 at pc 0x000003a63a5b bp 0x7ffe5ff01be0 sp 0x7ffe5ff01bd0
READ of size 8 at 0x617000000b10 thread T0
    #0 0x3a63a5a in btDiscreteDynamicsWorld::removeConstraint(btTypedConstraint*) thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:647
    #1 0x2b6d671 in SpaceBullet::remove_constraint(ConstraintBullet*) modules/bullet/space_bullet.cpp:522
    #2 0x2a840cc in ConstraintBullet::destroy_internal_constraint() modules/bullet/constraint_bullet.cpp:55
    #3 0x2a34d33 in BulletPhysicsServer::free(RID) modules/bullet/bullet_physics_server.cpp:1536
    #4 0xa51be51 in Joint::_update_joint(bool) scene/3d/physics_joint.cpp:39
    #5 0xa51f684 in Joint::_notification(int) scene/3d/physics_joint.cpp:121
    #6 0xa588ed5 in Joint::_notificationv(int, bool) scene/3d/physics_joint.h:39
    #7 0xa594f1b in ConeTwistJoint::_notificationv(int, bool) scene/3d/physics_joint.h:207
    #8 0xe0ad46b in Object::notification(int, bool) core/object.cpp:943
    #9 0x8f5ff58 in Node::_propagate_exit_tree() scene/main/node.cpp:305
    #10 0x8fa7a9c in Node::_set_tree(SceneTree*) scene/main/node.cpp:2523
    #11 0x8f805c1 in Node::remove_child(Node*) scene/main/node.cpp:1249
    #12 0x8f583cc in Node::_notification(int) scene/main/node.cpp:167
    #13 0x16adc1f in Node::_notificationv(int, bool) scene/main/node.h:46
    #14 0x16dd651 in Spatial::_notificationv(int, bool) scene/3d/spatial.h:58
    #15 0xa589007 in Joint::_notificationv(int, bool) scene/3d/physics_joint.h:39
    #16 0xa594f1b in ConeTwistJoint::_notificationv(int, bool) scene/3d/physics_joint.h:207
    #17 0xe0ad46b in Object::notification(int, bool) core/object.cpp:943
    #18 0xe09bd7d in Object::_predelete() core/object.cpp:386
    #19 0xe0d3668 in predelete_handler(Object*) core/object.cpp:2016
    #20 0x1538ba2 in void memdelete<Object>(Object*) core/os/memory.h:117
    #21 0x908390c in SceneTree::_flush_delete_queue() scene/main/scene_tree.cpp:1103
    #22 0x906ea00 in SceneTree::iteration(float) scene/main/scene_tree.cpp:478
    #23 0x152d0d3 in Main::iteration() main/main.cpp:1897
    #24 0x142dda0 in OS_X11::run() platform/x11/os_x11.cpp:3181
    #25 0x13aab93 in main platform/x11/godot_x11.cpp:56
    #26 0x7fc97c728b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)
    #27 0x13aa799 in _start (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x13aa799)

0x617000000b10 is located 16 bytes inside of 767-byte region [0x617000000b00,0x617000000dff)
freed by thread T0 here:
    #0 0x7fc97e02404f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x10c04f)
    #1 0x29f3216 in btFreeDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:31
    #2 0x29f33e0 in btAlignedFreeDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:86
    #3 0x29f34be in btAlignedFreeInternal(void*) thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:260
    #4 0x29b74bd in btCollisionObject::operator delete(void*) thirdparty/bullet/BulletCollision/CollisionDispatch/btCollisionObject.h:126
    #5 0x29b7737 in btRigidBody::~btRigidBody() thirdparty/bullet/BulletDynamics/Dynamics/btRigidBody.h:178
    #6 0x2a5d977 in CollisionObjectBullet::destroyBulletCollisionObject() modules/bullet/collision_object_bullet.cpp:136
    #7 0x2a5c3d1 in CollisionObjectBullet::~CollisionObjectBullet() modules/bullet/collision_object_bullet.cpp:111
    #8 0x2a6565f in RigidCollisionObjectBullet::~RigidCollisionObjectBullet() modules/bullet/collision_object_bullet.cpp:233
    #9 0x2ab6da4 in RigidBodyBullet::~RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:302
    #10 0x2ab6df7 in RigidBodyBullet::~RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:309
    #11 0x2a33763 in BulletPhysicsServer::free(RID) modules/bullet/bullet_physics_server.cpp:1511
    #12 0xa0e9e55 in CollisionObject::~CollisionObject() scene/3d/collision_object.cpp:394
    #13 0xa4b4d7d in PhysicsBody::~PhysicsBody() scene/3d/physics_body.h:40
    #14 0xa42aaae in RigidBody::~RigidBody() scene/3d/physics_body.cpp:1071
    #15 0x1538d63 in void memdelete<Object>(Object*) core/os/memory.h:120
    #16 0x908390c in SceneTree::_flush_delete_queue() scene/main/scene_tree.cpp:1103
    #17 0x906ea00 in SceneTree::iteration(float) scene/main/scene_tree.cpp:478
    #18 0x152d0d3 in Main::iteration() main/main.cpp:1897
    #19 0x142dda0 in OS_X11::run() platform/x11/os_x11.cpp:3181
    #20 0x13aab93 in main platform/x11/godot_x11.cpp:56
    #21 0x7fc97c728b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)

previously allocated by thread T0 here:
    #0 0x7fc97e024448 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
    #1 0x29f31fc in btAllocDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:26
    #2 0x29f326c in btAlignedAllocDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:66
    #3 0x29f3491 in btAlignedAllocInternal(unsigned long, int) thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:247
    #4 0x2ae400a in btCollisionObject::operator new(unsigned long) thirdparty/bullet/BulletCollision/CollisionDispatch/btCollisionObject.h:126
    #5 0x2ab481f in RigidBodyBullet::RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:285
    #6 0x2a024b1 in BulletPhysicsServer::body_create(PhysicsServer::BodyMode, bool) modules/bullet/bullet_physics_server.cpp:454
    #7 0xa3ed048 in PhysicsBody::PhysicsBody(PhysicsServer::BodyMode) scene/3d/physics_body.cpp:176
    #8 0xa428ae4 in RigidBody::RigidBody() scene/3d/physics_body.cpp:1048
    #9 0x8ebdd48 in Object* ClassDB::creator<RigidBody>() (/home/rafal/Pulpit/godot/bin/godot.x11.tools.64s+0x8ebdd48)
    #10 0xde44150 in ClassDB::instance(StringName const&) core/class_db.cpp:541
    #11 0xbb742b6 in SceneState::instance(SceneState::GenEditState) const scene/resources/packed_scene.cpp:154
    #12 0xbba8070 in PackedScene::instance(PackedScene::GenEditState) const scene/resources/packed_scene.cpp:1692
    #13 0x15273d7 in Main::start() main/main.cpp:1750
    #14 0x13aaac3 in main platform/x11/godot_x11.cpp:55
    #15 0x7fc97c728b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)

SUMMARY: AddressSanitizer: heap-use-after-free thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:647 in btDiscreteDynamicsWorld::removeConstraint(btTypedConstraint*)
Shadow bytes around the buggy address:
  0x0c2e7fff8110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2e7fff8140: 00 07 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e7fff8150: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c2e7fff8160: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e7fff8170: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e7fff8180: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e7fff8190: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e7fff81a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e7fff81b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc

Minimal reproduction project:
The-worst-Godot-test-project2.zip

New minimal project - The-worst-Godot-test-project2.zip
WARNING: assert_no_constraints: A body with a joints is destroyed. Please check the implementation in order to destroy the joint before the body.
   At: modules/bullet/rigid_body_bullet.cpp:465.
=================================================================
==13116==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000026c10 at pc 0x000003caffdd bp 0x7ffe31a31250 sp 0x7ffe31a31240
READ of size 8 at 0x617000026c10 thread T0
    #0 0x3caffdc in btDiscreteDynamicsWorld::calculateSimulationIslands() thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:743
    #1 0x3ca5a9f in btDiscreteDynamicsWorld::internalSingleStepSimulation(float) thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:475
    #2 0x3e19ad7 in btSoftRigidDynamicsWorld::internalSingleStepSimulation(float) thirdparty/bullet/BulletSoftBody/btSoftRigidDynamicsWorld.cpp:88
    #3 0x3ca4492 in btDiscreteDynamicsWorld::stepSimulation(float, int, float) thirdparty/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:434
    #4 0x2dc970a in SpaceBullet::step(float) modules/bullet/space_bullet.cpp:366
    #5 0x2c9a076 in BulletPhysicsServer::step(float) modules/bullet/bullet_physics_server.cpp:1567
    #6 0x1586ecd in Main::iteration() main/main.cpp:1960
    #7 0x14857a0 in OS_X11::run() platform/x11/os_x11.cpp:3192
    #8 0x1401ba3 in main platform/x11/godot_x11.cpp:56
    #9 0x7f00c56a0b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)
    #10 0x14017a9 in _start (/usr/bin/godots+0x14017a9)

0x617000026c10 is located 16 bytes inside of 767-byte region [0x617000026c00,0x617000026eff)
freed by thread T0 here:
    #0 0x7f00c6f9c04f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x10c04f)
    #1 0x2c57204 in btFreeDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:31
    #2 0x2c573ce in btAlignedFreeDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:86
    #3 0x2c574ac in btAlignedFreeInternal(void*) thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:260
    #4 0x2c1b4ab in btCollisionObject::operator delete(void*) thirdparty/bullet/BulletCollision/CollisionDispatch/btCollisionObject.h:126
    #5 0x2c1b725 in btRigidBody::~btRigidBody() thirdparty/bullet/BulletDynamics/Dynamics/btRigidBody.h:178
    #6 0x2cc1b7d in CollisionObjectBullet::destroyBulletCollisionObject() modules/bullet/collision_object_bullet.cpp:136
    #7 0x2cc05d7 in CollisionObjectBullet::~CollisionObjectBullet() modules/bullet/collision_object_bullet.cpp:111
    #8 0x2cc9865 in RigidCollisionObjectBullet::~RigidCollisionObjectBullet() modules/bullet/collision_object_bullet.cpp:233
    #9 0x2d1afaa in RigidBodyBullet::~RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:302
    #10 0x2d1affd in RigidBodyBullet::~RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:309
    #11 0x2c97751 in BulletPhysicsServer::free(RID) modules/bullet/bullet_physics_server.cpp:1511
    #12 0xa5db2a7 in CollisionObject::~CollisionObject() scene/3d/collision_object.cpp:395
    #13 0xa9b1641 in PhysicsBody::~PhysicsBody() scene/3d/physics_body.h:40
    #14 0xa92699c in RigidBody::~RigidBody() scene/3d/physics_body.cpp:1071
    #15 0x159295d in void memdelete<Object>(Object*) core/os/memory.h:117
    #16 0x94c5ae6 in SceneTree::_flush_delete_queue() scene/main/scene_tree.cpp:1109
    #17 0x94b0ac8 in SceneTree::iteration(float) scene/main/scene_tree.cpp:478
    #18 0x1586ccb in Main::iteration() main/main.cpp:1953
    #19 0x14857a0 in OS_X11::run() platform/x11/os_x11.cpp:3192
    #20 0x1401ba3 in main platform/x11/godot_x11.cpp:56
    #21 0x7f00c56a0b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)

previously allocated by thread T0 here:
    #0 0x7f00c6f9c448 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10c448)
    #1 0x2c571ea in btAllocDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:26
    #2 0x2c5725a in btAlignedAllocDefault thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:66
    #3 0x2c5747f in btAlignedAllocInternal(unsigned long, int) thirdparty/bullet/LinearMath/btAlignedAllocator.cpp:247
    #4 0x2d483a2 in btCollisionObject::operator new(unsigned long) thirdparty/bullet/BulletCollision/CollisionDispatch/btCollisionObject.h:126
    #5 0x2d18a25 in RigidBodyBullet::RigidBodyBullet() modules/bullet/rigid_body_bullet.cpp:285
    #6 0x2c6649f in BulletPhysicsServer::body_create(PhysicsServer::BodyMode, bool) modules/bullet/bullet_physics_server.cpp:454
    #7 0xa8e8b6a in PhysicsBody::PhysicsBody(PhysicsServer::BodyMode) scene/3d/physics_body.cpp:176
    #8 0xa9249d2 in RigidBody::RigidBody() scene/3d/physics_body.cpp:1048
    #9 0x92fde44 in Object* ClassDB::creator<RigidBody>() (/usr/bin/godots+0x92fde44)
    #10 0xe3b1aac in ClassDB::instance(StringName const&) core/class_db.cpp:541
    #11 0xc0900c0 in SceneState::instance(SceneState::GenEditState) const scene/resources/packed_scene.cpp:154
    #12 0xc0c3ea6 in PackedScene::instance(PackedScene::GenEditState) const scene/resources/packed_scene.cpp:1692
    #13 0x15810a5 in Main::start() main/main.cpp:1810
    #14 0x1401ad3 in main platform/x11/godot_x11.cpp:55
    #15 0x7f00c56a0b6a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26b6a)

Still happens with 3.2.2

WARNING: assert_no_constraints: A body with a joints is destroyed. Please check the implementation in order to destroy the joint before the body.
At: modules/bullet/rigid_body_bullet.cpp:465.

As indicated by the warning, the RigidBody is being deleted when it is still attached to a Joint.
#43898 and its 3.2 version #43899 address the read from freed memory issue.


Adding linter

fix: adding server side linter

@MStokluska can you rebase please?

@MStokluska could you add a step to the CircleCI job that builds and tests the server that will run yarn lint? It should be done after the tests and build step.


Add new adopter

This pull request adds PITS Global Data Recovery Services as an adopter
Thanks, have a wonderful day

/ok-to-merge documentation


Compose element gets unbound twice

unbind() gets called twice after changing the composed view-model
<template>
    <compose view-model.bind="viewModel"></compose>
</template>

export class Welcome {

  constructor() {
    this.viewModel = 'test';

    setTimeout(() => {
        this.viewModel = 'test2';
    }, 2000);
  }
}

And what's written to the console (using test.js and test2.js):
Test bind
test.js:9 Test unbind
aurelia-logging-console.js:38 DEBUG [templating] importing resources for http://localhost:9000/dist/test2.html []
test.js:9 Test unbind
test2.js:5 Test2 bind

It seems like part of our example is missing. Can you first see if this is fixed in the latest release? If not, can you provide the rest of the code?

Updating to pre-beta fixed the bug.
Great job :thumbsup:

Excellent. Thanks!


Teleporting in 1.10.1?

Hey there - anyone know if teleporting is working (or how to get it working) in 1.10.1? When I try any destination I am ported to high in the air and then I eventually fall/die. By the way I did try the Unstuck button but all times I fall/die.

Apologies if this issue/fix has been confirmed already elsewhere. Thank you.

Hi, I don't have the game anymore (and also time) to test or work on this but it was working fine on 1.10, so I would assume it's still working on a minor patch like 1.10.1


Test failure on parrot

With rakudo-parrot, "make test" produces this output:
t/binary-and-long-line.t .. ===SORRY!=== Error while compiling t/binary-and-long-line.t
Unrecognized character name LEFT CORNER BRACKET
at t/binary-and-long-line.t:25
------> unicode-chars = "\c[ LEFT CORNER BRACKET⏏ ]\c[ SNOWMAN ]\c[
t/binary-and-long-line.t .. No subtests run

Rakudo on Parrot is dead, and so is Parrot. Closing.


Remove network attributes from store.json & store-armhf.json files

With the changes implemented in https://github.com/openfaas/faas-swarm/commit/e36f90b36f5b81498ea7dc018b3cf0b48127f7a1 the network attribute can be ascertained by the swarm backend.
This issue is to remove the network values from the store.json & store-armhf.json files

Tightened the scope as arm64 doesnt appear to have the network label yet

Please raise a PR when ready.


Provider wants to replace the Gitlab group

I wanted to retrofit a manually created Gitlab group setup:
import * as gitlab from "@pulumi/gitlab"

export const cumundi = new gitlab.Group("cumundi",
    {
        name: "Cumundi",
        path: "cumundi",
        visibilityLevel: "private",
        requestAccessEnabled: true
    },
    {
        import: "cumundi"
    }
);

// more group memberships here

Running pulumi up resulted in a succesful import:
     Type                             Name                        Status                  Info
 +   pulumi:pulumi:Stack              00-infra-global-production  **creating failed**     1 error
 =   ├─ gitlab:index:Group            cumundi                     imported
 =   ├─ gitlab:index:GroupMembership  ringods                     imported
 +   ├─ gitlab:index:GroupMembership  maja                        **creating failed**     1 error
 +   ├─ gitlab:index:GroupMembership  benny                       **creating failed**     1 error
 +   └─ gitlab:index:Project          infra-00-global             created

But as you can see, I was missing the import information for users maja and benny. After fixing this in my Pulumi sources and running preview, I got this as output:
    pulumi:pulumi:Stack              00-infra-global-production
 +-  ├─ gitlab:index:Group            cumundi                     replace
 =   ├─ gitlab:index:GroupMembership  benny                       import
 =   └─ gitlab:index:GroupMembership  maja                        import

The Group got replace in the plan output??? How come?
To conclude, I overlooked this and ran up, which resulted in Pulumi dropping the whole group, but not recreating it:
Updating (production):

     Type                             Name                        Status
     pulumi:pulumi:Stack              00-infra-global-production
 +-  ├─ gitlab:index:Group            cumundi                     replaced
 =   ├─ gitlab:index:GroupMembership  benny                       imported
 =   └─ gitlab:index:GroupMembership  maja                        imported

Another preview gives me this:
Previewing update (production):

     Type                   Name                        Plan       Info
     pulumi:pulumi:Stack    00-infra-global-production             1 error
 =>  └─ gitlab:index:Group  cumundi                     import     1 error

Diagnostics:
  gitlab:index:Group (cumundi):
    error: Preview failed: refreshing urn:pulumi:production::00-infra-global::gitlab:index/group:Group::cumundi: GET https://gitlab.com/api/v4/groups/cumundi: 404 {message: 404 Group Not Found}

  pulumi:pulumi:Stack (00-infra-global-production):
    error: preview failed

I expect this is due to https://github.com/pulumi/pulumi/issues/3657.
If so - this applies:

This "replacement" should actually succeed and isn't truly a "replace" (it will just re-import the resource), but it is not the right experience.

Although I see @ringods notes explicitly that the replace did truly try to replace and did not succeed:

To conclude, I overlooked this and ran up, which resulted in Pulumi dropping the whole group, but not recreating it

Either way, I do expect https://github.com/pulumi/pulumi/issues/3657 is the root issue here.

It's been 3.5 years since the issue got opened, the referenced pu/pu got fixed, we change the import a few times, and we haven't received any new comments or upvotes. I'll assume the issue is fixed.


Specify GitHub in the manifest

This doesn't change the behavior of the extension, but makes sure that the extension only gets loaded into GitHub pages. You could probably messageIfFound() function in the inject.js file since this ensures it's only a Github page, but I didn't go that far.

I initially had gone this route (restricting to just the GitHub.com domain), but realized it would be limiting anyone that wanted to use this for GH Enterprise.
I'll look a bit more into dynamic permissions for Chrome extensions. I definitely don't like having to request access to all pages, but last time I checked, dynamic host permissions were pretty limited.

@DrewML Notifier for GitHub handles GitHub Enterprise in an option. You could look at how it does it: https://github.com/sindresorhus/notifier-for-github-chrome/blob/7d3edf98510c382735f3ece5e2ae58d4f9e38472/extension/options.html#L26-L29

Perfect! Thanks for the heads-up.


Figure 5 - style transfer diagram - overlapping text but only sometimes

Figure 5 looks fine in Chrome 70 (MacOS) and Safari 12 (MacOS) and Safari 12 (iOS) when the browser width is 1180px or greater but 1179px and below the words on the overlap:

On my Firefox 64 (Mac OS) the text overlaps even at the wider browser width, but my Firefox is highly customized so I can't be sure it's not something else.
On Chrome 70 (Windows 10) “content objective” and “aims” run together at all widths for me, but there's no change at 1180px.
IE/Edge (Windows 10) is the only browser I tried where it always looks right (!).

I'm not sure where the text is being built but if you put all the tspan elements on a line without x and y on each one after the first, it seems to put it in the right place:
<tspan x="629" y="12.3">The </tspan>
<tspan font-weight="500">content objective</tspan>
<tspan> aims </tspan>

Good catch, I thought I had found all of these—the underlying issue here was SF Pro Display vs SF Pro Text… never trust software to do your typesetting.


Error on importing GLB file

Describe the bug
Get this error when importing GLB file
  File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\scripts\addons\io_scene_gltf2\__init__.py", line 1109, in execute
    return self.import_gltf2(context)
  File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\scripts\addons\io_scene_gltf2\__init__.py", line 1137, in import_gltf2
    if self.unit_import(path, import_settings) == {'FINISHED'}:
  File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\scripts\addons\io_scene_gltf2\__init__.py", line 1157, in unit_import
    BlenderGlTF.create(gltf_importer)
  File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\scripts\addons\io_scene_gltf2\blender\imp\gltf2_blender_gltf.py", line 42, in create
    BlenderGlTF._create(gltf)
  File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\scripts\addons\io_scene_gltf2\blender\imp\gltf2_blender_gltf.py", line 49, in _create
    BlenderScene.create(gltf)
  File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\scripts\addons\io_scene_gltf2\blender\imp\gltf2_blender_scene.py", line 50, in create
    import_user_extensions('gather_import_scene_after_nodes_hook', gltf, gltf.data.scenes[gltf.data.scene], scene)
TypeError: 'NoneType' object is not subscriptable

location: <unknown location>:-1

To Reproduce
Steps to reproduce the behavior:

Import > GLB file
Error

Expected behavior
No error
Screenshots
Not applicable
.blend file/ .gltf
camera.zip
Version

OS: Windows 10
Blender Version: 3.1.2

Additional context
It works fine in Blender 2.91

Maybe already fixed, seems to work after copying addons/io_scene_gltf2 into my scripts/addons/ folder

Yes, this was #1603, which is now fixed.

@yuzotova Please open a new ticket with your test file


Ru translation

Hello again! Yeah, I translate this website only on my freetime ( othen in weekend ). On this week 4 days free and I will translate next little article to Russian. Thank you for merging!

Uniforms article translation looking like this


fix(query): impl serde for QueryArgs

:tada: This PR is included in version 0.5.1 :tada:
The release is available on:

GitHub release
v0.5.1

Your semantic-release bot :package::rocket:


Optimize generated docker images and update project's structure

Hi,
According to https://github.com/free5gc/free5gc/issues/39, this PR:

optimizes the generated docker images using a multi stage build to generate binaries and create an image called base which will be used to generate NFs images
changes fixed IPs to network aliases
updates the structure of the project to create a dockerfile per NF

Since I created a new project to launch a vagrant box with kernel 5.0.0-23-generic for testing purposes, I added it to the readme file.
This PR integrates the previous one: https://github.com/free5gc/free5gc-compose/pull/1
BR,

Maybe we can remove IP column in README and add webui row with
| webui | 5000 | db | MongoDBUrl: mongodb://db:27017  |


Benchmarking bot tests

DO NOT MERGE. THIS IS JUST FOR TESTING THE BOT.


Extend API to add/remove demo plugins

You can simply add a plugin with intermix.addPlugin("<PluginName>");. You can do this with the following names:

Sequencer
Synth
Sampler

intermix.addPlugin returns the UID of the created plugin instance. This should be possible with external plugins, too (see #117).


Fix drag and drop text from outside the editor the inside editor

Issue
Drag and drop text from outside the editor inside the editor:

[x]  Line break are lost
[x]  Duplicated text

Duplicated #22


Make minimum size for secure memory a size_t.

The minimum size argument to CRYPTO_secure_malloc_init() was an int but ought
to be a size_t since it is a size.
From an API perspective, this is a change.  However, the minimum size is
verified as being a positive power of two and it will typically be a small
constant, so impact should be low to none.

[x] documentation is added or updated
[x] tests are added or updated

I wonder if there are any compilers which might complain about this if applications make this call? Does this deserve a CHANGE entry...or is it more like the "const" changes we make which don't usually have one.

test/secmem.c didn't actually have a size_t cast -- one in a comment, one inside #if 0 because it tests an infinite loop condition.  Nonetheless, I've removed the cast from the second argument of both but not from the first where a wider than int value is required.
I've updated the documentation.
@mattcaswell, I've added a note in the history section of the documentation.  CHANGES seems excessive but I'm happy to add an entry.

Is a vote required for this?
Technically, it is a breaking API change.  Realistically, it's very safe.  Unless, someone is taking the address of the function and assigning it to a variable.

I wonder if there are any compilers which might complain about this if applications make this call? Does this deserve a CHANGE entry...or is it more like the "const" changes we make which don't usually have one.

One potential compile-time problem could be if a caller passes in a clearly negative value, thought is is very unlikely since there was already the dynamic check for negative input, which should have lead to a run-time error.
I've just tried out with gcc on code configured with --strict-warnings. Interestingly, it does not complain if a -1 is passed as actual argument and one changes the parameter type from  int  to  size_t.

I think this is a bad thing to do, for a couple of reasons

It could break something
It works fine now
It's a lot of changes (doc, code, casts) for no real gain other than nerd esthetics.
It doesn't fully address the issue #10995 where this was used as an example.
It establishes a bad precedent of "we think it safe let's fix it" which is counter to one of 3.0's stated goals: "most applications should work just be recompiling."  The slippery slope is very very slippery. :)

a couple of reasons

It amuses me that you list 5 reasons:
https://xkcd.com/1070/

It's a lot of changes (doc, code, casts) for no real gain other than nerd esthetics.

I've heard that consistency is a good thing :wink:

I've heard that consistency is a good thing

Okay, I'll take the bait since you're trying to use my words against me:  how does this PR make things more consistent?

It amuses me that you list 5 reasons:

I was sloppy and didn't go back and fix the first line. :)  The bullets just kept a-comin'.
I had an English class once where we had to sort sentence in order:
A couple of the clarinetists...
Most of the clarinetists...
Many of the clarinetists...
A few of the clarinetists...

Wish I could find that page; it went on for 50 or so lines!

The event that a caller provides a negative value for the minsize parameter is very unlikely because it make no sense and typically the value will be a simple constant, so would be obvious.
And even if so, what could really go wrong here if that is subsequently taken as a huge unsigned value?
AFAICS:

a huge about of heap memory is reserved successfully, which is again very unlikely in itself
the caller obtains an error result, as before with the hitherto version of the function

how does this PR make things more consistent?

Easy.  Consistent use of size_t for passing sizes.

So "fix" SSL_read and SSL_write?  Those are far more glaring inconsistencies.  And fixing this one, which was done deliberately and correctly... shrug.  I've said why I think this is a bad idea and given explanations.  Oh well.

Actually, I see no reason why we shouldn't fix SSL_read and SSL_write in a similar way...
However, that shouldn't be a factor in approving or not approving this PR.

As there are concerns on doing this and related changes right now, how about simply deferring them to after 3.0?
There is nothing urgent in here.

Major releases are the time for changes like this -- API compatibility isn't guaranteed at these points.  A deferral until after 3.0 will be a long time after...
Changing the int to a size_t is definitely break ABI compatibility.

Well... I'm not a committer so my opinion is not so influent. But I think that if you wait after 3.0 for stuff like this, the change will never happen.
A major release like 3.0 is not only an opportunity to massively change the internals, but is also the best opportunity to improve the API wherever is required.
Is not only a matter of nerd esthetics but is a matter of type safety and coerence.

Major releases are the time for changes like this -- API compatibility isn't guaranteed at these points. A deferral until after 3.0 will be a long time after...

Now I'm confused. @kroeckx explained to me a couple of months ago that API changes for 3.0 should be kept to the minimum: https://github.com/openssl/openssl/pull/10504#issuecomment-558249028

OpenSSL 3.0 is supposed to remain as compatible as possible, we expect most applications to just need to rebuild and not make any changes. Anything that requires them to make changes needs to wait until at least 4.0.

Major releases are when we can make changes.  For 3.0, the decision was made that we are aiming for a high level of source compatibility and this will limit changes.
I can't see this particular change breaking anyone.

Merged to master.  Thanks for the discussion.


fix floating-point overflow problem of tanh

Fix issue #302 .

Coverage increased (+0.02%) to 62.185% when pulling 8c2ad8da22c2a778bd5c5516d2ebb3b9c2501db6 on hedaoyuan:fp_exception into 568d9cff1d9afaddffda79a3844475c365c22d06 on baidu:develop.


Make GHE more testable

fixes #443
GitHub Enterprise 2.14
$ GHE_VERSION=2.14 npm test -- --no-coverage

><EMAIL_ADDRESS>test /home/derek/code/octokit/routes
> tap --coverage --timeout 60 'test/**/*-test.js' "--no-coverage"

 PASS  test/integration/landing-page-test.js 1 OK 724ms
 PASS  test/unit/options-urls-test.js 9 OK 882ms
 PASS  test/integration/all-endpoints-test.js 964 OK 10s
 PASS  test/integration/scope-endpoints-test.js 964 OK 10s
 PASS  test/integration/single-endpoint-test.js 964 OK 10s

  🌈 SUMMARY RESULTS 🌈

Suites:   5 passed, 5 of 5 completed
Asserts:  2902 passed, of 2902
Time:     11s

GitHub Enterprise 2.15
$ GHE_VERSION=2.15 npm test -- --no-coverage

><EMAIL_ADDRESS>test /home/derek/code/octokit/routes
> tap --coverage --timeout 60 'test/**/*-test.js' "--no-coverage"

 PASS  test/integration/landing-page-test.js 1 OK 764ms
 PASS  test/unit/options-urls-test.js 9 OK 856ms
 PASS  test/integration/all-endpoints-test.js 966 OK 11s
 PASS  test/integration/scope-endpoints-test.js 966 OK 11s
 PASS  test/integration/single-endpoint-test.js 966 OK 11s

  🌈 SUMMARY RESULTS 🌈

Suites:   5 passed, 5 of 5 completed
Asserts:  2908 passed, of 2908
Time:     11s

GitHub Enterprise 2.16
$ GHE_VERSION=2.16 npm test -- --no-coverage

><EMAIL_ADDRESS>test /home/derek/code/octokit/routes
> tap --coverage --timeout 60 'test/**/*-test.js' "--no-coverage"

 PASS  test/integration/landing-page-test.js 1 OK 768ms
 PASS  test/unit/options-urls-test.js 9 OK 907ms
 PASS  test/integration/all-endpoints-test.js 970 OK 10s
 PASS  test/integration/scope-endpoints-test.js 970 OK 11s
 PASS  test/integration/single-endpoint-test.js 970 OK 11s

  🌈 SUMMARY RESULTS 🌈

Suites:   5 passed, 5 of 5 completed
Asserts:  2920 passed, of 2920
Time:     11s

GitHub Enterprise 2.17
$ GHE_VERSION=2.17 npm test -- --no-coverage

><EMAIL_ADDRESS>test /home/derek/code/octokit/routes
> tap --coverage --timeout 60 'test/**/*-test.js' "--no-coverage"

 PASS  test/integration/landing-page-test.js 1 OK 794ms
 PASS  test/unit/options-urls-test.js 9 OK 858ms
 PASS  test/integration/scope-endpoints-test.js 992 OK 11s
 PASS  test/integration/all-endpoints-test.js 992 OK 11s
 PASS  test/integration/single-endpoint-test.js 992 OK 11s

  🌈 SUMMARY RESULTS 🌈

Suites:   5 passed, 5 of 5 completed
Asserts:  2986 passed, of 2986
Time:     11s

GitHub Cloud
$ npm test -- --no-coverage

><EMAIL_ADDRESS>test /home/derek/code/octokit/routes
> tap --coverage --timeout 60 'test/**/*-test.js' "--no-coverage"

 PASS  test/integration/landing-page-test.js 1 OK 737ms
 PASS  test/unit/options-urls-test.js 9 OK 853ms
 PASS  test/integration/all-endpoints-test.js 1006 OK 11s
 PASS  test/integration/scope-endpoints-test.js 1006 OK 11s
 PASS  test/integration/single-endpoint-test.js 1006 OK 11s

  🌈 SUMMARY RESULTS 🌈

Suites:   5 passed, 5 of 5 completed
Asserts:  3028 passed, of 3028
Time:     12s

That looks good 👍
Shall we add the testing to CI? The .github/main.workflow file would need to be updated
https://github.com/octokit/routes/blob/f3d5d7c88788514dc1b4f1bcb05f3065536118d5/.github/main.workflow#L1-L24
I wonder if you see a way to test all GHE versions without configuring the number? That way we would test al enterprise versions with a single action and wouldn’t need to update the workflow file each time an enterprise version gets added/removed

after going down several paths, i've landed on a pretty light touch approach in the form of adding a test:ci npm script (to .github/main.workflow as well): 97aee804d5f133c4871d2f1e0492071f338a7542

Can you run a test for a single *.JSON for either api.github.com or one of the GHE versions now? If so, could you amend CONTRIBUTING.md please?

done


scrcpy: 2.6.1 -> 2.7

Description of changes
https://github.com/Genymobile/scrcpy/releases/tag/v2.7
Diff: https://github.com/Genymobile/scrcpy/compare/v2.6.1...v2.7
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Tested basic functionality.


Fix scanner's inability to match keywords

Definition of Done
Allow for scanner to match keywords from the keywords array from the database, allowing them to be used for the algorithm and display purposes.

[t:45] Messed around with school email and team gmail account to find out why the keywords are not matching. Learned that tokenizEmailContents and the matching does occur, but for what ever reason the keywords do not match.

Messed around more and found out that the array that was being opened in the other emails was empty. For some reason I had assigned the message to the array we wanted to use for holding the keywords, and it worked on my email. Easy fix once I figured out what was wrong.
[t:45]


D0S.DustManager and D0S.Factory - Dust... conflict?

Ok, let me lay out what I think is an issue: DustManager won't up tier a single dust (as in count==1) and FactoryManager only leaves a single dust. This for me has led to more than a few instances of manual up tiering. (Poor me, I know) Plus, for an added kicker, 2nd floor crafter happily eats everything, right down to the last dust, making it rather dangerous to use with low numbers of higher tier dust (not your problem, just mentioning some pain points).
I'm just entering mid game, so maybe this won't be an issue later on.
Not really looking for a fix, just thought I'd mention it as a possible point for a second look.
Love your scripts/tools - thanks for everything!
EDIT: I suppose if I could ask for anything:

Crafting ore lumps up to X tier using available previous tier dust
A setting to strictly save a certain amount of Ore per tier (think 100 rubber saplings)

Yes, you're right about this discrepancy. It's caused some low-level annoyance for a while, and I've thought about changing it but have been too lazy to do so.
There is a setting to save a certain amount of ore per tier... for the uptierer, not the factory. Factory is already too complicated ^_^;
The reason for the limitation of the uptierer not using the last dust is both for safety, and also (more importantly) this keeps the inventory from being reordered. The factory doesn't do this, which means it will rearrange your items when it uses them all up.
The solution to using both together is to ensure that the up-tierer stays in front of the factory. I.e. don't make so much stuff that the factory runs through all the dust. If you stick to that, it's never an issue, because the uptierer does all the uptiering and the factory never does.
I never use the built-in crafter, but it's interesting to know that it doesn't save anything. Doesn't really surprise me, though.

Thanks again for your reply. As I expected, a few days after posting this, with the appropriate perks and finally getting access to the power plant second floor, I was processing ore at a rate fast enough that dust manager became obsolete. Thanks for the detailed explanation though!

The dust manager is still relevant at that point; you can get a lot of extra high-tier dust from all the T1 dust you pull in (but you have to be willing to idle in the factory).
When it really becomes obsolete is when you get factory floor 2.


update to version 4.1

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


refactor(ssh,ui): use messages for web ssh connection

sequenceDiagram
    participant Term
    participant Browser
    participant Server
    participant Device

    alt Failed to capture the credentails
        Browser ->>+ Server: Send user's credentails securelly
        Server --x- Browser: error
    else Success
        Browser ->>+ Server: Send user's credentails securelly
        Server ->>- Browser: Receive token's ID
    end

    alt Token ID is expired
        Browser ->>+ Server: Request web socket connection
        Note over Server,Browser: The token expires in 30 seconds after created.
        Server ->>- Browser: error
    else Cols or Rows exceed the limit
        Browser ->>+ Server: Request web socket connection
        Server ->>- Browser: error
    else Success
        Browser ->> Server: Request web socket connection
        Server ->> Browser: Confirm websocket connection
    end

    alt Credentails are invalid on device
        Browser ->>+ Term: Init terminal
        Browser ->>+ Server: Request PTY
        Server ->>+ Device: Try to the device
        Device ->>- Server: Authentication error
        Server ->>- Browser: Send authentication error message
        Browser ->> Term: Write authenticaion error message
        Term ->>- Browser: Done
    else
        Browser ->>+ Term: Init terminal
        Browser ->>+ Server: Request PTY
        Server ->>+ Device: Connect to the device

        par Send message
            Device ->> Server: Send data
            Server ->> Browser: Send data
            Browser ->> Term: Write data
        and data
            Term ->> Browser: Receive data
            Browser ->> Server: Receive message
            Server ->> Device: Receive data
        end

            Device ->>- Server: Disconnect
            Server ->>- Browser: Send disconnect
            Browser ->> Term: Write disconnect message
            Term ->>- Browser: Done
    end


Connection closed with an error. Unknown error

Web socket connection to Azure services returns error after trying to connect from several browser tabs:
{"type":7,"error":"Connection closed with an error."}

Several tabs succeed to connect to sockets and receive mesages, but most of connections returned this type of error. I have no clue what is going wrong because no error description returned.
I am using Azure services on Free plan, but dashboard shows that all is under the message/connection limits (max 18 connections):

I have tried to configure signalR options EnableDetailedErrors, but with no result - no error description.
Startup.cs:
services.AddSignalR(conf =>
{
    conf.HandshakeTimeout = TimeSpan.FromSeconds(300);
    conf.EnableDetailedErrors = true;
})
.AddAzureSignalR(configure =>
{
    configure.ConnectionString = connString;
    configure.ConnectionCount = 1;
    configure.AccessTokenLifetime = TimeSpan.FromHours(24);
});

app.UseAuthentication();
app.UseMvc();
app.UseFileServer();

app.UseAzureSignalR(routes =>
{
    routes.MapHub<ChatHub>("/hub/chat");
});

Javascript client:
var connection = new HubConnectionBuilder()
      .withUrl('/hun/chat', { accessTokenFactory: () => this.authService.getAccessToken() })
      .build();
connection.serverTimeoutInMilliseconds = 300000;
connection.start();

Microsoft.AspNetCore.SignalR: 1.0.2
Microsoft.Azure.SignalR: 1.0.0-preview1-10015

Could you send your service instance name to me via email? My email address is kevinzha<at>microsoft.com (change <at> to @).

@ToniaDemchuk I didn't see any unusual errors in our backend logs. But I do noticed that quite a lot of connections are closed right after receiving the handshake request.
 I want to confirm whether server code is closing the client connection.

It is not normal. Each client connection shouldn't have impact on the others. It sounds like the underlying connection between your server and SignalR service is broken. Then all client connections running on top are closed too.
Could you share more details such as debug logs from your app?

@ToniaDemchuk Is this still an issue?

Thank you for reply.
I cannot reproduce it anymore. Debug logs don't show any suspicious items.

Then it is probably just intermittent network issue.
I will close this issue for now. Feel free to reopen it or create another issue if you have further questions.


:sparkles: Add evidential classification

[ ] Handle the number of epochs for the simulated annealing
[x] Add the method to the ReadMe

It seems ready to merge for me. We may need to detail the loss more in the tutorial + add some more tests, but we will do this in the PR on main or just on dev!
Thanks again for your help :)


i18n(zh-cn): add astro-syntax.mdx

What kind of changes does this PR include?
add astro-syntax.mdx
Description
translate astro-syntax.mdx

astro-syntax.mdx is not ready to translate.

You can check the translation Status in https://i18n.docs.astro.build/

Also repeated with https://github.com/withastro/docs/pull/2982

ok, thx, i will close it


[KYUUBI #5529][AUTHZ] Support create table command for Delta Lake

Why are the changes needed?
To close #5529.
Support create table command for Delta Lake in Authz.
https://docs.delta.io/latest/delta-batch.html#create-a-table
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Was this patch authored or co-authored using generative AI tooling?
No.

Nice! cc @bowenliang123 and @AngersZhuuuu

Cool, let's bring Ranger authorisation to Delta in Kyuubi Authz !

delta lake also supports creating a table at a path
-- Create or replace table with path
CREATE OR REPLACE TABLE delta.`/tmp/delta/people10m` (
  id INT,
  firstName STRING,
  middleName STRING,
  lastName STRING,
  gender STRING,
  birthDate TIMESTAMP,
  ssn STRING,
  salary INT
) USING DELTA

Shall we also add UTs for this case?

Path-based tables are supported in Authz now. No path based policies (eg. HDFS service def) of Ranger are supported.

LGTM. Would be more clare if we reorder the test cases in the order for the non-partitioned table, the partitioned table, and then the create/replace table. Or just separated into separated ut.

Thanks, Updated.

Path-based tables are supported in Authz now. No path based policies (eg. HDFS service def) of Ranger are supported.

Does Delta Lake have an option for the globally disabled path-based table, similar to how spark.sql.runSQLOnFiles works? If not, I think we can introduce a configuration in Kyuubi AuthZ to disable this behavior temporarily, prior to the completion of the path-based table feature. WDYT? cc @yaooqinn

@AngersZhuuuu is currently working one the path/uri authorization
What's the plan of CREATE OR REPLACE TABLE delta./tmp/delta/people10m

Path-based tables are supported in Authz now. No path based policies (eg. HDFS service def) of Ranger are supported.

Does Delta Lake have an option for the globally disabled path-based table, similar to how spark.sql.runSQLOnFiles works? If not, I think we can introduce a configuration in Kyuubi AuthZ to disable this behavior temporarily, prior to the completion of the path-based table feature. WDYT? cc @yaooqinn

https://github.com/delta-io/delta/blob/8639c411890a5c77386f04e2282fcf4caa401eff/spark/src/test/scala/org/apache/spark/sql/delta/DeltaDDLUsingPathSuite.scala#L125
Delta Lake is also controlled by spark.sql.runSQLOnFiles.

@AngersZhuuuu is currently working one the path/uri authorization
What's the plan of CREATE OR REPLACE TABLE delta./tmp/delta/people10m

== Analyzed Logical Plan ==
ReplaceTable [StructField(id,IntegerType,true)], TableSpec(Map(),Some(DELTA),Map(),None,None,None,false), true
+- ResolvedDBObjectName org.apache.spark.sql.delta.catalog.DeltaCatalog@2f9addd4, [delta, /tmp/delta/people10m]

== Optimized Logical Plan ==
CommandResult AtomicReplaceTable org.apache.spark.sql.delta.catalog.DeltaCatalog@2f9addd4, delta.`/tmp/delta/people10m`, [StructField(id,IntegerType,true)], TableSpec(Map(),Some(DELTA),Map(),None,None,None,false), true, org.apache.spark.sql.execution.datasources.v2.DataSourceV2Strategy$$Lambda$1627/2047805101@71b3ba5a
   +- ReplaceTable [StructField(id,IntegerType,true)], TableSpec(Map(),Some(DELTA),Map(),None,None,None,false), true
      +- ResolvedDBObjectName org.apache.spark.sql.delta.catalog.DeltaCatalog@2f9addd4, [delta, /tmp/delta/people10m]

Delta Lake is also controlled by spark.sql.runSQLOnFiles.

thank you for your input. @zml1206

Codecov Report

Merging #5530 (facd8f7) into master (5b9290a) will decrease coverage by 0.10%.
Report is 2 commits behind head on master.
The diff coverage is n/a.

:exclamation: Current head facd8f7 differs from pull request most recent head 10138d8. Consider uploading reports for the commit 10138d8 to get more accurate results

@@             Coverage Diff              @@
##             master    #5530      +/-   ##
============================================
- Coverage     61.42%   61.32%   -0.10%
  Complexity       23       23
============================================
  Files           598      598
  Lines         34254    34254
  Branches       4488     4488
============================================
- Hits          21039    21007      -32
- Misses        11095    11118      +23
- Partials       2120     2129       +9

see 10 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

thanks, merging to master(v1.9.0).


Fix some static analyzer warnings (issue 11965)

This fixes only those warnings, as reported by https://lgtm.com/projects/g/mozilla/pdf.js?mode=list, that make sense (as far as I'm concerned).
Hence this patch leaves the following things unaddressed:

The "recommendation"-category, since it only complains about unused variables. However, note that all of those cases are purposely included and that there's thus ESLint-disable comments added to explictly allow them.
The "warning"-category, which still contains two complaints. However, as far as I can tell, they are both false positives.

Given first of all the false positives of the LGTM static analyzer, and secondly that we'd need to add (essentially duplicated) disable-comments for the unused variable cases, it's not entirely clear to me if we actually want to work towards including LGTM in the PDF.js project (e.g. running alongside Travis) or if we should just close issue #11965.

/botio-linux preview

Thank you! I'd say this is enough to close the issue. If we ever want to do more with this, we can always do so.

However, as far as I can tell, they are both false positives.

I don't think the useless comparison test in /src/display/pattern_helper.js is a false positive. At line 121, y1 === y2 is evaluated only when both these conditions are met:

At line 117, y < y2 evaluates to true
At line 119, y < y1 evaluates to false

If y is lower than y2 and not lower than y1, then y1 cannot be equal to y2 (unless any of those variables can be modified between the comparisons, which is not the case here).

However, as far as I can tell, they are both false positives.

I don't think the useless comparison test in /src/display/pattern_helper.js is a false positive. At line 121, y1 === y2 is evaluated only when both these conditions are met:
1. At line 117, `y < y2` evaluates to true

2. At line 119, `y < y1` evaluates to false

If y is lower than y2 and not lower than y1, then y1 cannot be equal to y2 (unless any of those variables can be modified between the comparisons, which is not the case here).

That's certainly an interesting find; thank you!
However, since that we're currently not intending on integrating LGTM officially for this repo, we can probably just leave this as-is for now. Given that there's similar code in the else-branch below (with a valid y2 === y3 check), I do wonder if there's perhaps a bug in the code as-is, however it seems better to just leave it alone for now since we're (currently) not aware of any PDF documents that'd benefit from (general) changes to this code.


Add package trot

I've decided to archive the repository and close it

any specific reason for archiving the repo? :(

The formatting of the external resources has changed significantly. We have decided to archive them as we don't have time to deal with them...

On second thought, it doesn't seem so hard to deal with! I'll unarchive if I can fix it soon. thx :)