text:
Add support for producing and consuming REST APIs

Currently, HTTP-RPC requests encode a method name in the URL and use either GET or POST to invoke the method. This is by design, and is appropriate for SOAP-like use cases that require custom verbs. However, it does not support applications that require REST semantics. This limits HTTP-RPC's usefulness in many situations.
HTTP-RPC should be extended to support REST-style APIs in addition to SOAP-like APIs. Method arguments would still be encoded in the query string or request body, but verbs would be restricted to GET, POST, PUT, and DELETE. Note that path-encoded (e.g. /users/10) or header-encoded argument values would not be supported.
An annotation would be provided to map an HTTP verb and resource path to a particular service method. For example:
@Resource(name="user", action="get")
public Map<String, Object> getUser(int userID) {
    ...
}

@Resource(name="user", action="post")
public int addUser(String firstName, String lastName) {
    ...
}

The current invocation behavior could be preserved if this annotation is not provided (i.e. the method would be accessible by name via GET or POST). Alternatively, a service could be flagged as requiring REST semantics in web.xml, in which case un-annotated methods would simply be ignored.
Additionally, an HTTP method argument would be added to the invoke() method of the client libraries. This would allow a caller to specify the verb, rather than leaving it to the implementation's discretion. Non-REST methods could be invoked by specifying either GET or POST as the verb type. The existing method name argument would be repurposed as "path", to reflect its more general intent.
Note that this change may necessitate changes to or elimination of the service descriptor. In earlier versions, a given path was guaranteed to refer to a single method. Now, a path may refer to up to four methods, each of which will have different arguments and return types. It is not possible to encode this information using the current descriptor structure.

Another option is to simply drop support for arbitrary verbs and make HTTP-RPC a REST-only framework. In this case, only annotated methods would be published, and the descriptor structure would be simpler to define.

One outstanding question is how to handle templates. Currently, templates can be applied to any method, since all methods are invoked via GET or POST. However, in a REST environment, it may not make sense to apply a template to the output of a PUT, POST, or DELETE, which typically return little or no content. Instead, it may make more sense to limit templates to GET handlers.

Note that attachments should only be supported for POST and PUT requests. They do not make sense for GET or DELETE, and should generate an exception on the client if specified with a GET or DELETE request.

Template and descriptor support have been dropped. Still need to think through all of the potential implications of moving to a fully REST-based model.

Support for the RPC annotation has been added to RequestDispatcherServlet, and the test service has been annotated to preserve the existing API. However, the client libraries have not been updated to accept an HTTP verb yet.

The Java client library has been updated and tested with the annotated service methods.

The JavaScript and Objective-C libraries have been updated and tested.

It appears that servlets do not handle multipart form content with PUT requests. As a result, PUTs have been updated to use the query string like GET and DELETE.
Further, since this effectively limited the use of attachments to POST requests only, support for attachments was dropped.

The Android client apps (test and demo) have been updated.

It would probably be valuable to support path-encoded arguments as well as query string arguments. Without this, it will be difficult or impossible to implement common REST collection patterns such as the following:

GET /collection - return an array containing the collection's contents
GET /collection/resource - return a single object from the collection

The RPC annotation could potentially be extended to support this as follows:
@RPC(method="GET", path="users/{userID}")

Multiple variables should be supported.

It seems like both JAX-RS and Spring use a leading "/" character in path specifications, so HTTP-RPC probably should as well.

After some investigation, it seems like the proposed approach isn't significantly different from what is provided by JAX-RS or Spring. As a result, a better option might be to retire the server component and focus on the client libraries.
Also, it may be possible to restore streaming and template support on the server as an extension to JAX-RS or Spring, rather than a replacement for it. This will require a little more investigation.

Path argument support has been added to the Java and Objective-C clients; however, the JavaScript client has not been updated yet.

This has been mostly implemented but has not been fully tested yet.

This has been implemented and tested but has not been documented yet.

This is done.

repo: gk-brown/HTTP-RPC


text:
Implement force-deletion

For stacks in a DELETE_FAILED state

I think this is handled by https://github.com/glassechidna/stackit/blob/bb3ee3809b245d31fde3aaf2c6339a45b8b6237a/pkg/stackit/up.go#L65

source: gharchive/issue

repo: glassechidna/stackit

license_type: permissive

license_source: bigquery


text:
🛑 Schoelcher is down

In f794885, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in a2e8271 after 491 days, 13 hours, 50 minutes.

repo: glefait/martinique-public-websites

license: MIT

license_source: github-api


text:
🛑 Le Lamentin is down

In 5f30150, Le Lamentin (http://www.mairie-lelamentin.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Le Lamentin is back up in 1b90426 after 2 days, 7 hours, 36 minutes.


text:
🛑 Saint-Pierre is down

In 5c43e81, Saint-Pierre (https://saintpierre-mq.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Saint-Pierre is back up in 00f26ba after 5 minutes.


text:
🛑 Office du tourisme du centre de la Martinique is down

In c4c2713, Office du tourisme du centre de la Martinique (https://tourisme-centre.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Office du tourisme du centre de la Martinique is back up in e71afb8 after 9 minutes.


text:
🛑 Schoelcher is down

In 2044cff, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 309ad4e.


text:
🛑 Schoelcher is down

In 44c8dc7, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in c5108e9.


text:
🛑 Schoelcher is down

In 4c1ee75, Schoelcher (https://www.mairie-schoelcher.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schoelcher is back up in 97a24fe.


text:
Add missing highlight group to README

Add missing highlight group to README and remove unused diagnostics highlight groups.

Was just about to make this same pull request :clap:

source: gharchive/pull-request

authors: kuznetsss markstory


text:
structlog issue on el7 release

Describe the bug
Reconfigure fails likely because of a wrong version of structlog is installed on el7. See the stacktrace below.
To Reproduce
Just reconfigure the factory on el7
Screenshots
[mmascher@vocms0205 ~]$ sudo gwms-factory reconfig
Using default factory config file: /etc/gwms-factory/glideinWMS.xml
Reconfiguring the factory...
Traceback (most recent call last):
  File "/sbin/reconfig_glidein", line 24, in <module>
    from glideinwms.factory import glideFactoryConfig, glideFactoryLib, glideFactoryMonitorAggregator
  File "/usr/lib/python3.6/site-packages/glideinwms/factory/glideFactoryLib.py", line 33, in <module>
    from glideinwms.lib import (
  File "/usr/lib/python3.6/site-packages/glideinwms/lib/condorExe.py", line 10, in <module>
    from . import logSupport, subprocessSupport
  File "/usr/lib/python3.6/site-packages/glideinwms/lib/logSupport.py", line 418, in <module>
    structlog.processors.CallsiteParameterAdder(
AttributeError: module 'structlog.processors' has no attribute 'CallsiteParameterAdder'
Factory reconfiguration...                                 [FAILED]
[mmascher@vocms0205 ~]$ sudo vim /usr/lib/python3.6/site-packages/glideinwms/lib/logSupport.py
[mmascher@vocms0205 ~]$ sudo vim /usr/lib/python3.6/site-packages/glideinwms/lib/logSupport.py
[mmascher@vocms0205 ~]$ python3
Python 3.6.8 (default, Jun 20 2023, 11:53:23)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import structlog
>>> structlog.__version__
'17.2.0'
>>>

Info (please complete the following information):

GlideinWMS version: 3.10.3.rc2
OS version: el7
Priority: critical
Stakeholders: all
Components: factory

This also affects the frontend
Using default frontend config file: /etc/gwms-frontend/frontend.xml
Traceback (most recent call last):
  File "/sbin/reconfig_frontend", line 20, in <module>
    from glideinwms.creation.lib import (
  File "/usr/lib/python3.6/site-packages/glideinwms/creation/lib/cvWCreate.py", line 21, in <module>
    from glideinwms.lib import condorExe, condorSecurity
  File "/usr/lib/python3.6/site-packages/glideinwms/lib/condorExe.py", line 10, in <module>
    from . import logSupport, subprocessSupport
  File "/usr/lib/python3.6/site-packages/glideinwms/lib/logSupport.py", line 417, in <module>
    structlog.processors.CallsiteParameterAdder(
AttributeError: module 'structlog.processors' has no attribute 'CallsiteParameterAdder'
Upgrading the frontend[FAILED]

authors: brianhlin mmascher

repo: glideinWMS/glideinwms


text:
Don't prevent tab events

Allow users to tab outside the megadraft component. Discussed in #172

Lgtm

Hello, @joepio, thanks for contributing with Megadraft! this code will be on the next release.

authors: joepio vierno

repo: globocom/megadraft

license: mit


text:
Add new parameter origins

This parameter is used to try multiple origins/hosts for each relative URL.
When you have the same resource with same path, but hosted in multiple domains and the request for the first one fails, it will try the next.
Usage:
nautilus.config({
  origins: ['https://public.cdn.com', 'https://private.cdn.com', 'https://s3.com'],
  paths: { jquery: '/libs/jquery.min.js' }
});
nautilus(['jquery']);

It will try to load the script once in the following order:

https://public.cdn.com/libs/jquery.min.js
https://private.cdn.com/libs/jquery.min.js
https://s3.com/libs/jquery.min.js
/libs/jquery.min.js

Hi @fmatoss, thanks for contributing.
I'll review it. In this weekend 👍

Hi @fmatoss, thanks for contributing. This is a nice idea!
Can you add this info in README?

Done @raphamorim

@fmatoss I merged in a another repo: https://github.com/raphamorim/nautilus.js

I'll release versions from that.
This repo will exists only for nautilus.js globocom's purporse.
This changes make sense, then I'll split this developmente. 'Cause globocom nautilus's usage is a very specific uncommon purpose.

authors: fmatoss raphamorim


text:
SHORTED FILE NAME

https://music.apple.com/id/music-video/secrets-from-a-girl-whos-seen-it-all/1614925583
THIS ONE DL AS Secrets from a Girl (Who's Seen it A
I GUESS IT HAS'NT REACH THE LIMIT

Everything is truncated 40 characters to follow iTunes directory standard.

authors: evafans glomatico

repo: glomatico/gamdl


text:
Cookies.txt file not being found

Keeps saying the cookies.txt isn’t there and I’ve placed it in every folder labeled gamdl. Is there a specific folder or place where I’m supposed to place it that I don’t know of?

The same thing happens when a run on android termux terminal.

You have not place the cookies on the current directory. Do it like so or specify the location using the cookies path option.

authors: glomatico jhonata-ms rkuli


text:
Link not work in documentation

Description
A link is not work in Inputs component
CodeSandbox/Snack link
No response
Steps to reproduce

Go to 'Link'
Click on "Unstyled" tab
Click on "link"
See 404 not found

gluestack-ui Version
1.0.0
Platform

[ ] Expo
[ ] React Native CLI
[ ] Next
[ ] Web
[ ] Android
[ ] iOS

Other Platform
No response
Additional Information
I will can fix it. Basically, the link should be "https://gluestack.io/ui/docs/theme-configuration/customizing-theme"

Thanks for reporting.
Yes, you can send a PR for the same.

Ok. Thank you very much

Hey @jishat, This issue has been resolved. website will be up in few hours. Thanks for your contribution.

authors: Viraj-10 jishat makkarMeenu

repo: gluestack/gluestack-ui


text:
Subtitles are one on top of the other

This seems to happen only with the "The lighthouse" movie

Hi! Thanks for the report. Unfortunately I don't have the lighthouse in my region, and I can't immediately reproduce the problem on another title :(

Do both the primary and secondary subtitles move down when the progress bar disappears?
Could you show me the console log output?
Do you have any other Netflix related addons installed?

Ciao! Happy to help!

Hi! Thanks for the report. Unfortunately I don't have the lighthouse in my region, and I can't immediately reproduce the problem on another title :(
1. Do both the primary and secondary subtitles move down when the progress bar disappears? Yes, they move down a bit but they remain one up the other

2. Could you show me the console log output? Could you explain me how, please :) i just receive the messages you see below.

3. Do you have any other Netflix related addons installed? no other addons realted to Netflix.

18:39:51.079 Alcuni cookie utilizzano l’attributo “SameSite“ consigliato in modo non corretto 5
18:40:05.670 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 6 background.js:1
sendMessage moz-extension://46c9e57a-791e-419d-9d18-a3d053d55903/background.js:1
18:40:52.558 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 4 background.js:1
sendMessage moz-extension://46c9e57a-791e-419d-9d18-a3d053d55903/background.js:1
18:41:05.532 NotFoundError: No such JSWindowActor 'DevToolsFrame' 22
18:41:10.772 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 2 background.js:1
sendMessage moz-extension://46c9e57a-791e-419d-9d18-a3d053d55903/background.js:1
18:41:45.376 Error: Unknown file format
p moz-extension://5a9b8482-9d9e-42d8-8acb-a97375ade58a/background.js:1
setup moz-extension://5a9b8482-9d9e-42d8-8acb-a97375ade58a/background.js:1
parse moz-extension://5a9b8482-9d9e-42d8-8acb-a97375ade58a/background.js:1
$ moz-extension://5a9b8482-9d9e-42d8-8acb-a97375ade58a/background.js:1
background.js:1:9159
fetchExif moz-extension://5a9b8482-9d9e-42d8-8acb-a97375ade58a/background.js:1
18:41:45.926 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. background.js:1
18:42:05.191 Questa pagina si trova in modalità Quirks. Questo potrebbe avere effetto sul layout della pagina. Per la modalità standard utilizzare “”. background.js
18:42:05.247 Could not find any MenuItem with id: root background.js:1:157846
18:42:05.258 È stato fornito a “view-source:moz-extension://5a9b8482-9d9e-42d8-8acb-a97375ade58a/background.js” un cookie partizionato o accesso alle risorse di archiviazione in quanto è caricato in un contesto di terze parti e il partizionamento di stato dinamico è attivo.
18:42:05.288 Could not find any MenuItem with id: autofill background.js:1:157846
18:42:05.289 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 5 background.js:1
18:43:21.370 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 2 background.js:1

Hey sorry for the long wait. Still wasn't able to reproduce this on any other movie/show :( Since it only happens on this 1 movie I'm going to close this for now - but let me know if it happens on any other shows.

authors: filippogiad gmertes

repo: gmertes/NflxMultiSubs


text:
Integrate caching system with hugginface cards

It will resolve issues with cache versioning.
Materials:

https://huggingface.co/transformers/model_sharing.html

Could you maybe elaborate on where you'd want to add model versioning ?
The current example script suggests that huggingmolecules uses the pytorch lightning trainer for training the model rather than a custom wrapper, so at what point of the pipeline would this addition be ? Do we want to edit the save_edit fn to include pushing to huggingface hub
https://github.com/gmum/huggingmolecules/blob/7307936f98ca38ace91575bc24a6e5c0d861b6b8/src/huggingmolecules/models/models_api.py#L75
Or do we want to have a custom TrainerWrapper around the standard PyTorch Lightning Trainer

repo: gmum/huggingmolecules


text:
Inconsistent sub-slide behavior with nested bullet points

Consider the following RemarkJS/Markdown:
---

* AAA

--
    * ...BBB
--
    * ...CCC

The above produces the desired effect: First show AAA, then "next slide" show BBB as a sub-bullet, then "next slide" show CCC at same sub-level as BBB.
But why does there have to be a blank link between * AAA and --?
Consider this:
* AAA
--
    * ...BBB
--
    * ...CCC

In the above, * ...BBB is appended to the previous point so it looks like * AAA*...BBB
Now consider this (line return between each bullet)
* AAA

--
    * ...BBB

--
    * ...CCC

In this, AAA shows fine. BBB shows fine. But when you navigate to slide 3, you see CCC but the spacing between AAA/BBB/CCC has completely changed. For some reason, in this case, <p>'s are added to each <li>. Why is that? This doesn't happen for just AAA and AAA/BBB. It only happens in case of 3+ subelements/subslides.

bump Hoping someone has a fix in the works for this. How do I start a bounty?
---

## Containers (LXC)

* OS-level virtualization method
--

* Allows running multiple, isolated systems, using a single kernel ("host")
--

* Kernel provides _cgroup_ functionality
    * CPU/memory/disk/network
    * No need for complete OS install
    * No device emulation/hypervisor
???
cgroup - control group (created by google, merged into 2.6.24, 2008)
--

* "Lightweight" virtual machine
--

* Local file system
--

* Accessible over network
--

* Container itself is isolated process
--

* "Baremetal" performance

@tripu Any discovery here? This is issue is highest priority for us @Percona.

Here's another example where return inside blockquote creates issues similar to above:
---

## Run Sample Application

* On `app`, start the application and verify
    * Use another window for this or use `screen`
```sql
app# prepare_sysbench_oltp.sh

app# run_sysbench_oltp.sh
```
* Is replication flowing to all the nodes?
* Observe the sysbench transaction rate

@utdrmac

This is issue is highest priority for us @percona.

So where is your PR to fix it? :wink:

@mschilli87 I'm not a programmer. I rely on the code creators to fix bugs.

@utdrmac: I think 5 messages to > 200 people should be sufficient to point out a problem without offering a solution. The people working on this usually do so for free in their personal time after work. So I doubt that by 'bumping' this issue it is going to be solved sooner.

I spent the better part of today researching more into this. I discovered that having 4 space indentation produces an incorrect result though I'm not sure why. For whatever reason, the nested bullet point line is having an additional carriage return appended to the end. This appended line then gets sent to Marked for rendering. According to the Commonmark spec, the extra carriage return will create a "loose" list which adds the p tags. Ok, fine but why is an additional return being added in the first place? There's no difference between the above line: "foo" and "foo1" Why is foo1 being treated differently? I found 1 possibility which is a regex match against the beginning 4 spaces which matches CODE in lexer.js. I tried modifying this regex to match against 5 spaces, but that did not change anything.

As far as I know, indentations have meaning in markdown.
So, when using 2 spaces for subpoints like this:
- Topic
  - Sub topic 1

The Sub topic 1 is recognized as a child bullet.
When adding -- with an empty line following:
- Topic
--

  - Sub Topic 1
--

  - Sub Topic 2

You should get the desired effect.

Looks fixed, so I'm closing it and documented it in the wiki
https://github.com/gnab/remark/wiki/HTML-CSS-JS-samples

authors: abelards mschilli87 theseer utdrmac

repo: gnab/remark


text:
Conda forge package

FYI I am trying to build a conda forge package for libmolgrid at https://github.com/conda-forge/staged-recipes/pull/20891
I also plan to add one for gnina. Those 2 packages should help a lot of users as they will be built against multiple versions of python, cuda and numpy.
For now, the packages will be dependant on cuda and so not available for OSX.
It would be great to modify the build system to build CPU only version of molgrid and gnina (if it's technically possible).
ping @dkoes

xref with https://github.com/gnina/gnina/issues/168

The molgrid conda package is available at https://github.com/conda-forge/molgrid-feedstock
It's only for Linux at the moment. Any help is welcome to make it OSX and Windows compatible. Then it's easy to maintain the builds on conda forge for a wide range of system, boost, CUDA versions, etc.
I don't think we'll do the same for gnina at the moment.

repo: gnina/libmolgrid


text:
what is the goal of this project and how it differs from gnoscan?

It's a genuine question: why do we need to spend time on this tool today? What makes Gnoscan not the best option to improve before developing a competitor? I believe this should be outlined in a README.

@moul
The goal of this project is to provide an easy "glance" UI for a Gno node cluster, something that's currently not possible with Gnoscan (you'd need to run X gnoscan instances for X nodes, and would still not get the data that this tool aggregates).
It's meant to be used for local cluster development, but also remote cluster management -- you can easily spin up a cluster and a gnostats agent that feeds into a public dashboard, similar to a public Grafana dashboard
Check this Ethereum instance to get the idea of what the tool does

Thanks, I have a few questions:

Did you ask @gnolang/onbloc team if they would consider improving Gnoscan? It may be in their interest to have the best tool in the space.
How urgent is our need for this now rather than later? I might not fully understand, but I feel we don't need it immediately. Could you provide more insight on who will use it and how?
How essential is it for us to have this as an official tool rather than as a community-driven package from Gnoverse? It seems like a nice-to-have tool that we could expect the community to develop, possibly with a bounty.

authors: moul zivkovicmilos

repo: gnolang/gnostats-ui


text:
Use persistent storage

Making use of the persisted fee storage. For testing purposes I turned the store/load functions into a trade which can be implemented in memory (like today) or via going to disk. For the unit tests, we are using the in-memory components.
Test Plan
Load frontend pointed to local orderbook. Swap tokens until you see the metamask signature popup (don't sign yet). Restart orderbook. Sign order and see that it doesn't get rejected.

How does one load the front end pointed at local instance? Sounds fancy and useful.

@bh2smith by using http://localhost:8080/api/v1 here. Maybe we should add those instructions to their README.


text:
Sometimes added safe doesn't have name

Description
Environment

Browser:
Wallet: MetaMask
Safe:
Environment:

production/prod (rinkeby)

Steps to reproduce

search for the steps?

Expected result
Obtained result
Screenshots

Just today worked in the hot fix PR on xDai https://pr2647--safereact.review.gnosisdev.com/xdai/app/#
I have created a new safe , added existed , sent transactions and closed tab with the app( addressbook contained 2 safes and 2 owners).
Now if I open PR for xDai , there are 2 safes without name and addressbook is empty.
Any ideas why all addressbook related data were lost ?

Additional note: only information about safes added using the add safe flow were missed in Settings and addressbook - faced today in PR https://pr2657--safereact.review.gnosisdev.com/rinkeby/app/#/safes/0xAC5809Cb86680C3Cfb9803667F77ec029B2E481B/address-book.

@katspaugh and @dasanra , the original issue is not fixed.
Again the full list in the addressbook was cleaned for me on the manual page refresh.

Tested the PR #2654 on the Polygon in one tab( added safe and etc.)
in another tab Rinkeby was opened for the same PR
I have added safes on Rinkeby , switched owners in MM a few times
returned to the tab with polygon
switched MM to Polygon from Rinkeby
refreshed page manually

Current result: The addressbook was cleaned fully on Polygon

repo: gnosis/safe-react


text:
Creating BSC safe gets stuck on "Loading your safe.."

Description
Creating a BSC safe gets stuck on the final stage after pressing the button "Get Started", showing "Loading your safe". I've waited for too long (5-10m) with different wallets and different browsers.
Environment

Browser: Chrome, Safari
Wallet: MetaMask
Safe: ??
Environment:

BSC (mainnet)

Steps to reproduce

Connect wallet
Select BSC network
Continue until end
"Create"
"Get Started

Expected result
Navigate to safe.
Obtained result
"Loading your safe".
Screenshots

There are indexing issues related to rate limiting applied by binance. I will close this issues as this is unrelated to the Safe web interface.

authors: mustache-commits rmeissner


text:
🛑 Blockscout is down

In 2745a65, Blockscout (https://blockscout.com/gnosis/chiado) was down:

HTTP code: 521
Response time: 436 ms

Resolved: Blockscout is back up in d5051e3 after 5 minutes.

repo: gnosischain/chiado-uptime


text:
Update dappnode content

What

The way the consensus client and execution client are installed in a different way in dappnode. I have uploaded the images that show the new stakers UI and updated the content of the guide on how to install the packages.

Thanks @tropicar !! Will merge it on #325

authors: alebanzas tropicar

repo: gnosischain/documentation


text:
Replace Arch specific kernel copy hack with more generic solution

This MR reverts the Arch specific commit, splits KernelPath() into KernelPath() & ModulePath(), reusing the last one to implement a shorter and more common solution.
In particular: Many platforms store the kernel under /usr/lib/modules/$uname_r/vmlinuz - perhaps because systemd expects it, to enable hibernate.
As added bonus - there is no need for a initramdisk generator, which tends to be responsible for copying the kernel in /boot.
Tl:Dr: Shorter, more generic code and fewer dependencies \o/
Big shout out to @gasinvein for the original suggestion.

Thanks for the prompt reply. If you can tell me what is needed to get things merged, that would be appreciated.
Even trivial MRs like https://github.com/go-debos/fakemachine/pull/68 remain open.

For me on Fedora 34 it instantly falls back to looking for kernels /boot.
Using strace I can see it tries to access /usr/lib/modules/5.13.19-200.fc34.x86_64/5.13.19-200.fc34.x86_64/vmlinuz - which doesn't exist.

Confirming this works on Fedora 34.

@evelikov Can you rebase this on latest main please ?

Done, needed a double-take since master was silently renamed to main.
Don't mind which name is used, yet a PSA would have been useful.

authors: evelikov gasinvein obbardc

repo: go-debos/fakemachine


text:
Open issue count not updated when closing through commits/PR merges

Gitea version (or commit ref): ge0ecddc11
Git version: 1.12.0+dev-401
Operating system: N/A
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[x] Yes: https://try.gitea.io/bkraul/TestProject/issues/
[ ] No
[ ] Not relevant

Log gist:

Description
Issue count indicators are not being properly updated when the issues are closed via commit messages or PR merges.
Steps to reproduce:

Create a new issue.
Add a commit to the project wit the Closes #... instruction.
Push the commit.
The issue will close as expected.
The count of open issues will not be updated and you will still see the count as if the issue had not been closed.
Restarting (recreating the docker container) updates the count.
...

Screenshots
Issue created:

Committing and pushing the change:

Issue closes, but count is not updated:

This issue appears related to #10360, and was supposed to have been fixed by #10364 but it seems it is not.

Please fix this. It makes me mad :/

OK it looks to me like the correct values are calculated but then they are incorrect overwritten by another call to update repository...

https://github.com/go-gitea/gitea/blob/89c94e2f8e871028492d5460fd3a10794f4ced1b/services/repository/push.go#L362-L365
Updates all the columns of the repository - overwriting the updated values.

authors: bkraul solaristhesun zeripath

repo: go-gitea/gitea


text:
Gitea keeping taking 100% CPU usage, and runs slowly in git pushing

Gitea version (or commit ref): 1.12.0+dev-440-gf5a20250a

Git version: git version 2.20.1

Operating system: Raspbian GNU/Linux 10 (buster) on Raspberry Pi zero w

Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Log gist:

Description
After upgrading the gitea to this version, I found that gitea runs very slow.
By checking the CPU usage, the CPU usage keeps 100%.
And I checked the ps, found that seems the gitea hook  processes (2395, 964) are taking up lots resource, I would like to know what are they and how can I track them, and how to stop them.
As far as I know, there is no git hook setting in my repo that runs on this server. So I think this could be the gitea's system hook.
And I see PID 2366 saying duchenpaul/homebridge-docker.git is executing hook, but there is no hook script set in that repo
As the PID 961, I dont know what is going on there.
I checked the log, only the sql that queried in the log, no errors
  928 ?        Ss     0:00  \_ sshd: git [priv]
  937 ?        S      0:00  |   \_ sshd: git@notty
  939 ?        Rsl   14:49  |       \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
  987 ?        Ss     0:00  \_ sshd: git [priv]
  996 ?        S      0:00  |   \_ sshd: git@notty
  998 ?        Rsl   12:43  |       \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
 1310 ?        Ss     0:00  \_ sshd: git [priv]
 1319 ?        S      0:00  |   \_ sshd: git@notty
 1321 ?        Rsl   10:04  |       \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
 2062 ?        Ss     0:00  \_ sshd: pi [priv]
 2071 ?        S      0:02  |   \_ sshd: pi@pts/1
 2074 pts/1    Ss     0:00  |       \_ -bash
 2482 pts/1    S+     0:00  |           \_ vi gitea.log
 2349 ?        Ss     0:00  \_ sshd: git [priv]
 2358 ?        S      0:00      \_ sshd: git@notty
 2360 ?        Ssl    0:03          \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
 2366 ?        Sl     0:00              \_ git-receive-pack duchenpaul/homebridge-docker.git
 2390 ?        S      0:00                  \_ bash hooks/post-receive
 2394 ?        S      0:00                      \_ bash ./hooks/post-receive.d/gitea
 2395 ?        Rl     4:55                          \_ /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini post-receive
  454 tty1     Ss+    0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
  525 ?        Ss     0:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
  619 ?        S      0:00  \_ php-fpm: pool www
  620 ?        S      0:00  \_ php-fpm: pool www
  586 ?        Ss     0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
  590 ?        S      0:00  \_ nginx: worker process
  654 ?        Ss     0:00 /lib/systemd/systemd --user
  680 ?        S      0:00  \_ (sd-pam)
  700 ?        Ss     0:00 /lib/systemd/systemd --user
  723 ?        S      0:00  \_ (sd-pam)
  753 ?        Ss     0:00 /usr/sbin/exim4 -bd -q30m
  961 ?        S      0:00 bash hooks/update refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
  963 ?        S      0:00  \_ bash ./hooks/update.d/gitea refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
  964 ?        Rl    14:45      \_ /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini update refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
 2175 ?        Ssl    1:49 /home/git/gitea/gitea web

Screenshots

Also, I observed that there are 3 processes called gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini  which taking up the most of CPU usage, what are they? How can it be stopped

Those three processes (939, 998 and 1321) sound like the server side of git clients. The fact that all of them have key-3 means that they all used the same credentials (public key). It's probably you trying to push, then cancelling, but for some reason the server side didn't realize about that yet.
But the culprit seems to be:
  964 ?        Rl    14:45      \_ /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini update refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22

which is Gitea's update hook on the repository. The 14:45 value is the accumulated CPU time used, which is not normal unless you're pushing on the Linux kernel source code in an old Pentium computer.
And yes, those hooks are Gitea's git plumbing that make things work behind the scenes.
Some ideas:

Try rebooting. Seriously. If for some fortuitous reason some process hanged on you but it's still locking some files, this will kill it.
Try doing a git fsck and a git gc on the repo via the admin menu. It's possible that there's something wrong with it.

Also, a Raspberry Pi Zero W doesn't have much RAM in it. Try checking whether your system is paging too much. Use the top program and hit the m key until the memory graph shows up:

Or maybe vmstat 3 999 (you cancel that with CTRL+C):

The si and so columns should be 0 most of the time. Paging in and out is something that really slows down the system.
(Note: don't take the values in my pictures as expected for your system: mine is a CentOS 7 VM with 12GB of RAM assigned to it).

Thank you for your replying,
I did a reboot again, looks ok for now.
I didn't cancel any transactions in-fight, from what I see for client side, all transactions are finished normally.
I believe PID 964 I referring to is blocked due to the high CPU usage of ssh transactions
My questions are:

Is there are timeout settings that cancel the in-fight ssh transactions from server side which taking too much time?
And is there a way to track back what is going on with those ssh transactions.

anyway, I will keep monitoring for 3 days, if it is ok, I will close this issue.
This gitea server is only serving myself, I think it still is able to handle the job well. 😄

output for vmstat 3 999
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   4036  68112  28512 141908    0    5   523    45  576 1210 17  9 72  2  0
 0  0   4036  68112  28512 141908    0    0     0     0  434  877  4  3 93  0  0
 0  0   4036  68112  28512 141908    0    0     0     0  405  856  6  1 93  0  0
 1  0   4036  68112  28512 141908    0    0     0     0  454  917  4  2 94  0  0
 3  0   4036  68112  28512 141908    0    0     0     0  532 1086  7  2 91  0  0

[Update] I found these 2 gitea serv process pops up again, while I didn't even do anything.
Anyone can help me find out who caused this?

pi@Venus ~ $ vmstat 3 999
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0  16172  84076  11680 106668    0    1    42     5  548  996 84  3 13  0  0
 3  0  16172  84076  11680 106668    0    0     0     0  554  958 99  1  0  0  0
 3  0  16172  84076  11680 106668    0    0     0     0  582 1027 96  4  0  0  0
 4  0  16172  84076  11680 106668    0    0     0     0  704 1296 98  2  0  0  0
 3  0  16172  84076  11680 106668    0    0     0     0  561 1015 97  3  0  0  0
 4  0  16172  84076  11680 106668    0    0     0     0  648 1170 97  3  0  0  0

Close for now, I found it could be my github desktop causing this. I change to GitExtensions, it never hangs.

Some git tools may check repo status on background.

Yes, you can tell from the log of github desktop, but how come the process stalls on the server side, and taking up all cpu resource, even the client is quit, the client end PC is powered off.

Not sure - we would need to see some logs from gitea as to what it's doing.
For example the update hook should just be basically empty - I've suggested it's removal entirely as it only can slow things down.

Yeah, I will reopen this issue, and set my gitea log level to debug to collect more info.
I didn't use update hook in any repo. only the post-receive one in a few repos just to deploy the code on remote server.
Now I found that even gitea dump can stall sometime, just hanging there and put the CPU in full throttle.

This is my log conf for debugging:
[log]
MODE      = file
LEVEL     = Debug
ROOT_PATH = /home/git/gitea/log
REDIRECT_MACARON_LOG = true
STACKTRACE_LEVEL = Debug
ENABLE_ACCESS_LOG = true
ENABLE_XORM_LOG = true
XORM = ,

is there any thing to add to help locate the problem?

It got stall again.
The PID 8480 takes 100% CPU usage. Even the gitea service is stoped by me.
 8469 ?        Ss     0:00  \_ sshd: git [priv]
 8478 ?        S      0:00  |   \_ sshd: git@notty
 8480 ?        Rsl    5:04  |       \_ /home/git/gitea/gitea --config=/home/git/gitea/custom/conf/app.ini serv key-6
 8486 ?        Ss     0:00  \_ sshd: pi [priv]
 8495 ?        S      0:00      \_ sshd: pi@pts/3
 8498 pts/3    Ss     0:00          \_ -bash
 8637 pts/3    R+     0:00              \_ ps xfa
  452 tty1     Ss+    0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
  568 ?        Ss     0:08 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
  653 ?        S      0:00  \_ php-fpm: pool www
  656 ?        S      0:00  \_ php-fpm: pool www
  633 ?        Ss     0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
  637 ?        S      0:00  \_ nginx: worker process
  725 ?        Ss     0:00 /usr/sbin/exim4 -bd -q30m
 7762 ?        Ss     0:00 /lib/systemd/systemd --user
 7766 ?        S      0:00  \_ (sd-pam)
 8334 ?        Ss     0:00 /lib/systemd/systemd --user
 8337 ?        S      0:00  \_ (sd-pam)
[ 09:52 - 192.168.31.150  ]
pi@Venus ~ $ ps -o lstart -o etime -p 8480
                 STARTED     ELAPSED
Mon Mar  9 09:46:14 2020       05:59
[ 09:52 - 192.168.31.150  ]
pi@Venus ~ $

This process starts at 09:46:14, I checked each log around that time, what I find is only Started Session c187 of user git. which my git client is tring to update the repo in background
syslog.log
access.log
auth.log
daemon.log
gitea.log

Have you tried running the fsck and gc? Those are important, given that you're using an SD-card to store the repos. If you are unable to do it via Gitea (e.g. system gets locked up before you get the chance), you can shutdown Gitea and run the commands yourself:
cd /home/git/gitea-repositories
( for user in * ; do cd "$user" ; echo "--- USER: $user ---"
    for repo in * ; do cd $repo ; echo "--- REPO: $repo ---"
        git fsck && git gc || exit
    cd .. ; done ; cd .. ; done )

(Change the initial path accordingly if required)

Note: STACKTRACE_LEVEL = Debug is excessive. You should change it to Error so important messages aren't buried too deep in the logs.

Yes, I did tried  fsck and gc, thank you for your bash snippt, it works like a charm, and ends perfectly.
I guess some bugs introduced between 1.11.0+dev-481-g1df701fd1(good) and 1.10.5+18-gd6657644a(bad) on arch linux-arm-6.
I just formated the SD card, to rule out my file system issue, and restore with the image I backupped days ago, with the gitea version: 1.11.0+dev-481-g1df701fd1.
Keeping running for hours, with some push pull actions performed. It is ok.
And I upgrade gitea to  master version which is 1.10.5+18-gd6657644a, problem reproduces. Now I rolled back to the previous version, to see if my assuming is correct.

Update
It seems that we had some issues when tagging our latest master image; it's 1.12.0+dev but the version string says 1.10.5. 😳

Original message (just in case it's useful)
But... those are not actual releases, and you are in fact downgrading. 🤔 Releases have only three digits in their version number, with nothing else after that.
Our latest release is 1.11.2. If you want the cutting edge (i.e. the version we're currently working on but is not polished), you could go for master. If you want to build from sources, you need to checkout exactly v1.11.2 (or master).
The master version is 1.12.0+dev-something, e.g. 1.12.0+dev-435-g6a57364dc which means "435 commits after the 1.12.0+dev tag was stablished", i.e. 435 commits after we've started working in 1.12.
1.10.5 is our latest patch release for the 1.10 branch, which we're still maintaining for severe bugs.

Yes, I noticed there is issue with version number. But I am sure there is issue in new version.
I download the gitea from the master folder here: https://dl.gitea.io/gitea/master/gitea-master-linux-arm-6, this is the newest version and where this thing occurs.

Upgrade to Gitea Version: 1.11.2, from github releases, problem persists.
I will downgrade version by version to narrow down the problem

Looks like the bug is between this 2 commits: ff24f81 - 0768823.
I am running v1.11.1(ff24f81), so far so good

Are you definitely running MySQL and not Sqlite?

MySQL: version: mysql  Ver 15.1 Distrib 10.3.22-MariaDB, for debian-linux-gnueabihf (armv8l) using readline 5.2
I dont think this is related to database.
the gitea server cannot handle some request from client side, these are processes like below, just handing there for hours, taking up all the CPU.
I wonder if there is a log to track this behavior? and interesting that this only happens on v1.11.2 in the github v1.11.x releases. Must be somewhere has issue.
gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini

The stacktraces are not helpful - they'd be more useful for figuring out why something is causing trouble once we have identified an issue. That being said they're not too difficult to remove from the logs for quick review.
I've looked at your daemon.log and I can't see any request to Gitea that is opened without closing and these are all at most around a second.
I'm looking at the others right now.

Do you have any logs from when there is a hang?

These are the logs I catched  when there is a hang

I dont know if this is appropraite but if you like, I could give you ssh access to my server, just to help navigate the problem.
my email: duchenpaul@gmail.com

Running grep git auth.log | grep sshd:session reveals only a few sessions greater than 2 minutes:
 "sshd[1969]:"    23.0
 "sshd[2114]:"     7.0
 "sshd[5028]:"    83.0
 "sshd[5363]:"    25.0
 "sshd[5574]:"     8.0
 "sshd[6406]:"    12.0

sshd[5028] is:
Mar  8 20:57:53 venus sshd[5028]: Accepted publickey for git from 61.155.3.10 port 6063 ssh2: RSA SHA256:
Mar  8 20:57:53 venus sshd[5028]: pam_unix(sshd:session): session opened for user git by (uid=0)
...
Mar  8 22:21:26 venus sshd[5028]: pam_unix(sshd:session): session closed for user git

But I can't see what was happening at that point because there are no logs.

Change a way to think, I pasted to process hanging details up there. This process started at Mar  9 09:46:14 and below is what I extracted from auth log, I believe this’s the hanging session, it doesn’t have a stop as I killed it manually or just reboot the server.
Mar  9 09:46:14 venus sshd[8469]: Accepted publickey for git from 192.168.2.1 port 50681 ssh2: RSA SHA256:rV+R5HyRUMVvl4taCsKmkY0IMhq7Rg0437wWScz6U1o
Mar  9 09:46:14 venus sshd[8469]: pam_unix(sshd:session): session opened for user git by (uid=0)
Mar  9 09:46:14 venus systemd-logind[253]: New session c187 of user git.

If you want to check the log, just see the time stamp  “ Mar  9 09:46:14” this is China time, utc +8 hrs , and the Gitea log is utc time, you should do a conversion

But I can't find a post or get to gitea that is not completed in daemon.log...

Of course you cannt find it. Let me summarize the problem:
The hanging of the process is introduced by git requests from client side.
My git client is github desktop, it does git fetch regularly and some of its request just hanging there.
Maybe I should post github desktop log.

I updated some info I collected in past few day at the issue report comment (the first comment)

I have the same problem after I updated gitea to 1.11.2. My system is Linux amd64 and I use sqlite.

One process call /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini post-receive on issue information.
@jedy If you exit all git clients and then upgrade to v1.11.2, are they still occured?

I can only suggest creating a core dump from one of those processes. We may at least be able to see what it's doing. The problem is that there's no way of sanitizing a core dump, so you should not share its raw contents.
If you've got delve or gdb installed, maybe you could open those cores ant tell us what are they doing.

OK I will get it back to you.

I compiled 1.11.2 with go 1.13.8. It seems OK now.

@jedy Could you compile a linux-arm-6 version for me if possible?

@duchenpaul Sorry. I don't have an arm environment.It got some error to cross compile on linux.

gdb backtrace of the hanging process:
[root@s60 git]# gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p 24006
0x000000000045b4e8 in runtime.step (p=..., pc=0xc000009828, val=0xc000009824, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
867	/usr/local/go/src/runtime/symtab.go: No such file or directory.
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file /var/git/gitea
Use `info auto-load python [REGEXP]' to list them.

Thread 1 (process 24006):
#0  0x000000000045b4e8 in runtime.step (p=..., pc=0xc000009828, val=0xc000009824, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
#1  0x000000000045a785 in runtime.pcvalue (f=..., off=11692510, targetpc=22398159, cache=0x0, strict=true, ~r5=<optimized out>) at /usr/local/go/src/runtime/symtab.go:687
#2  0x000000000045b276 in runtime.pcdatavalue (f=..., table=0, targetpc=22398159, cache=0x0, ~r4=<optimized out>) at /usr/local/go/src/runtime/symtab.go:822
#3  0x000000000043d17f in runtime.isAsyncSafePoint (gp=0xc000000180, pc=22398159, sp=824645152416, lr=<optimized out>, ~r4=<optimized out>) at /usr/local/go/src/runtime/preempt.go:396
#4  0x0000000000451858 in runtime.doSigPreempt (gp=0xc000000180, ctxt=0xc0000099d0) at /usr/local/go/src/runtime/signal_unix.go:329
#5  0x0000000000452429 in runtime.sighandler (sig=23, info=0xc000009bf0, ctxt=0xc000009ac0, gp=0xc000000180) at /usr/local/go/src/runtime/signal_unix.go:536
#6  0x0000000000451a49 in runtime.sigtrampgo (sig=23, info=0xc000009bf0, ctx=0xc000009ac0) at /usr/local/go/src/runtime/signal_unix.go:444
#7  0x00000000004707f3 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:389
#8  <signal handler called>
#9  0x000000000155c4cf in code.gitea.io/gitea/modules/public.glob..func1 (~r0=...) at /go/src/code.gitea.io/gitea/modules/public/bindata.go:14786
#10 0x0000000001565b52 in code.gitea.io/gitea/modules/public.init () at /go/src/code.gitea.io/gitea/modules/public/bindata.go:14787
#11 0x000000000044b0ea in runtime.doInit (t=0x42de880 <code.gitea.io/gitea/modules/public..inittask>) at /usr/local/go/src/runtime/stubs.go:12
#12 0x000000000044b0b7 in runtime.doInit (t=0x42ebb40 <code.gitea.io/gitea/routers/routes..inittask>) at /usr/local/go/src/runtime/proc.go:5409
#13 0x000000000044b0b7 in runtime.doInit (t=0x42edd00 <code.gitea.io/gitea/cmd..inittask>) at /usr/local/go/src/runtime/proc.go:5409
#14 0x000000000044b0b7 in runtime.doInit (t=0x42dd460 <main..inittask>) at /usr/local/go/src/runtime/proc.go:5409
#15 0x000000000043e4ce in runtime.main () at /usr/local/go/src/runtime/proc.go:190
#16 0x000000000046e8f1 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1373
#17 0x0000000000000000 in ?? ()

I ran strace on the hanging process. A lots of SIGURG popped up. I thought it's maybe related to the new preemptible runtime of Go which uses SIGURG. So I tried go 1.13.8. After a hour of running well, I think that's the problem.

I ran strace on the hanging process. A lots of SIGURG popped up. I thought it's maybe related to the new preemptible runtime of Go which uses SIGURG. So I tried go 1.13.8. After an hour of running well, I think that's the problem.

Nice catch! We need to look closely into this.

The backtrace shows only the first thread, which is probably not the most useful. 🙁

#10684 may fix this, it will be released on v1.11.3

My go version is Go1.13.8, is that accurate?

Here is my gdb dump, any thought on this?
git@Venus ~ $ gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p 2327
[New LWP 2328]
[New LWP 2329]
[New LWP 2330]
[New LWP 2331]
0x00065868 in runtime.step (p=..., pc=0x4409b50, val=0x4409b4c, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
867	/usr/local/go/src/runtime/symtab.go: No such file or directory.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/git/gitea/gitea.
Use `info auto-load python-scripts [REGEXP]' to list them.

Thread 5 (LWP 2331):
#0  runtime.futex () at /usr/local/go/src/runtime/sys_linux_arm.s:415
#1  0x00042568 in runtime.futexsleep (addr=0x411b8c4 <runtime.newmHandoff+12>, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:44
#2  0x0001a404 in runtime.notesleep (n=0x411b8c4 <runtime.newmHandoff+12>) at /usr/local/go/src/runtime/lock_futex.go:151
#3  0x0004c298 in runtime.templateThread () at /usr/local/go/src/runtime/proc.go:1806
#4  0x0004ad6c in runtime.mstart1 () at /usr/local/go/src/runtime/proc.go:1097
#5  0x0004aca8 in runtime.mstart () at /usr/local/go/src/runtime/proc.go:1062
#6  0x014ca07c in crosscall_arm1 () at gcc_arm.S:30
#7  0x014c9dc4 in threadentry ()
#8  0x014cb5a8 in start_thread (arg=0xa51ff2f0) at pthread_create.c:463
#9  0x014ff4c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (LWP 2330):
#0  runtime.futex () at /usr/local/go/src/runtime/sys_linux_arm.s:415
#1  0x00042568 in runtime.futexsleep (addr=0x445066c, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:44
#2  0x0001a404 in runtime.notesleep (n=0x445066c) at /usr/local/go/src/runtime/lock_futex.go:151
#3  0x0004c378 in runtime.stopm () at /usr/local/go/src/runtime/proc.go:1828
#4  0x0004cb88 in runtime.startlockedm (gp=0x44000e0) at /usr/local/go/src/runtime/proc.go:2001
#5  0x0004e290 in runtime.schedule () at /usr/local/go/src/runtime/proc.go:2557
#6  0x0004ee14 in runtime.goschedImpl (gp=0x4400700) at /usr/local/go/src/runtime/proc.go:2705
#7  0x0004ee9c in runtime.gosched_m (gp=0x4400700) at /usr/local/go/src/runtime/proc.go:2713
#8  0x0007671c in runtime.mcall () at /usr/local/go/src/runtime/asm_arm.s:285
#9  0x0444dfc8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (LWP 2329):
#0  runtime.futex () at /usr/local/go/src/runtime/sys_linux_arm.s:415
#1  0x00042568 in runtime.futexsleep (addr=0x445048c, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:44
#2  0x0001a404 in runtime.notesleep (n=0x445048c) at /usr/local/go/src/runtime/lock_futex.go:151
#3  0x0004c378 in runtime.stopm () at /usr/local/go/src/runtime/proc.go:1828
#4  0x0004cb88 in runtime.startlockedm (gp=0x44000e0) at /usr/local/go/src/runtime/proc.go:2001
#5  0x0004e290 in runtime.schedule () at /usr/local/go/src/runtime/proc.go:2557
#6  0x0004ebf8 in runtime.park_m (gp=0x44007e0) at /usr/local/go/src/runtime/proc.go:2690
#7  0x0007671c in runtime.mcall () at /usr/local/go/src/runtime/asm_arm.s:285
#8  0x0444de00 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (LWP 2328):
#0  runtime.usleep () at /usr/local/go/src/runtime/sys_linux_arm.s:575
#1  0x000531f8 in runtime.sysmon () at /usr/local/go/src/runtime/proc.go:4473
#2  0x0004ad6c in runtime.mstart1 () at /usr/local/go/src/runtime/proc.go:1097
#3  0x0004aca8 in runtime.mstart () at /usr/local/go/src/runtime/proc.go:1062
#4  0x014ca07c in crosscall_arm1 () at gcc_arm.S:30
#5  0x014c9dc4 in threadentry ()
#6  0x014cb5a8 in start_thread (arg=0xa6d2c2f0) at pthread_create.c:463
#7  0x014ff4c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (LWP 2327):
#0  0x00065868 in runtime.step (p=..., pc=0x4409b50, val=0x4409b4c, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
#1  0x00064d68 in runtime.pcvalue (f=..., off=7823431, targetpc=12885908, cache=0x0, strict=true, ~r5=<optimized out>) at /usr/local/go/src/runtime/symtab.go:687
#2  0x00065704 in runtime.pcdatavalue (f=..., table=0, targetpc=12885908, cache=0x0, ~r4=<optimized out>) at /usr/local/go/src/runtime/symtab.go:822
#3  0x000471e4 in runtime.isAsyncSafePoint (gp=0x44000e0, pc=12885908, sp=86869636, lr=<optimized out>, ~r4=<optimized out>) at /usr/local/go/src/runtime/preempt.go:396
#4  0x0005c9e0 in runtime.doSigPreempt (gp=0x44000e0, ctxt=0x4409c1c) at /usr/local/go/src/runtime/signal_unix.go:329
#5  0x0005d5d0 in runtime.sighandler (sig=23, info=0x4409c90, ctxt=0x4409d10, gp=0x44000e0) at /usr/local/go/src/runtime/signal_unix.go:536
#6  0x0005cc6c in runtime.sigtrampgo (sig=23, info=0x4409c90, ctx=0x4409d10) at /usr/local/go/src/runtime/signal_unix.go:444
#7  0x00079728 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_arm.s:534
#8  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Inferior 1 (process 2327) detached]
[ 19:07 - 192.168.31.150  ]
git@Venus ~ $

I'm having this same issue after updating to 1.11.2
I'm using sqlite and running under Fedora Server 30 x64
If someone needs more info regarding this I'm available.

1.11.3 is out in a few minutes. Please try with that and let us know your results. (Make sure no Gitea process is still active before upgrading).

Looking good so far, but we lost code language bar?
There used to have an indicator showing the percentage of languages in this project.

Language statistics are only in versions 1.12+

OK but found in 1.11.2

I'm not sure this is actually fixed -- if compiling with go 1.13 fixes it then master and new versions should still have the same problem using go 1.14 going forward

Yes @mrsdizzie We're gonna need to figure out what is causing this. The go release document is not very clear as to how this is supposed to be solved.

@zeripath @mrsdizzie let me know if you need any assistant from me

authors: duchenpaul guillep2k jedy joaodforce jolheiser lunny mrsdizzie zeripath


text:
404 error when Pull to repo with 'pull requests' disabled

Description
When we fork repo - forked repo is created with 'pull request' repo setting enabled. Old repo 'pull request' setting is left untouched. When we trying to create pull request from new repo to old repo we receive 404 'Not found' error if 'pull request' setting is disabled in old repo settings. More informative message is needed, or (more better) only repos with 'pull requests' enabled should shown in 'merge into' drop-down list.
Gitea Version
1.19.1
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots

Git Version
No response
Operating System
Flatcar
How are you running Gitea?
Kubernetes helm-chart on k3s running on flatcar linux.
Database
PostgreSQL

This may be even better (but I think that fork button should be shown anyway, but either in 'grayed' state - to show end-user that functionality is there but disabled or in 'normal' state with warning that 'you should enable PR on this repo beforehand.

So should we allow repo to be forked if pull request siabled? 🤔

Absolutely not. Not all forks are for the purpose as a sourcs of pull requests, they might become separate projects etc.

authors: barzog silverwind


text:
FreeBSD problem

Gitea version (or commit ref): 1.4.0-rc3
Git version: git version 2.13.0
Operating system: FreeBSD 11.1
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist:

Description
go get -d -u code.gitea.io/gitea
cd ******code.gitea.io/

ls
.changelog.yml  .gitattributes  assets          CONTRIBUTING.md Dockerfile      main.go         modules         README_ZH.md    templates
.drone.yml      .github         CHANGELOG.md    custom          docs            MAINTAINERS     options         README.md       vendor
.editorconfig   .gitignore      cmd             DCO             integrations    Makefile        package.json    routers
.git            .lgtm           contrib         docker          LICENSE         models          public          scripts

git tag -l
v0.9.99
v1.0.0
v1.0.1
v1.0.2
v1.1.0
v1.1.1
v1.1.2
v1.1.3
v1.1.4
v1.2.0
v1.2.0-rc1
v1.2.0-rc2
v1.2.0-rc3
v1.2.1
v1.2.2
v1.2.3
v1.3.0
v1.3.0-rc1
v1.3.0-rc2
v1.3.1
v1.3.2
v1.3.3
v1.4.0-rc1
v1.4.0-rc2
v1.4.0-rc3
root@web:~/go/src/code.gitea.io/gitea # git checkout v1.4.0-rc3
Previous HEAD position was 68134e64... Escape branch name in dropdown menu (#3692)
HEAD is now at 30226814... Changelog for 1.4.0-rc3 (#3679)
root@web:~/go/src/code.gitea.io/gitea # make generate build
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 7: Missing dependency operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 9: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 15: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 42: Missing dependency operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 43: warning: duplicate script for target "ifeq" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "ifeq" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 43: warning: duplicate script for target "(,)" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "(,)" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 43: warning: duplicate script for target "(Windows_NT)" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "(Windows_NT)" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 44: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 46: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 48: Missing dependency operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 49: warning: duplicate script for target "(,)" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "(,)" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 50: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 56: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 236: Missing dependency operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 237: warning: duplicate script for target "ifeq" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "ifeq" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 238: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 246: Missing dependency operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 247: warning: duplicate script for target "ifeq" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "ifeq" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 247: warning: duplicate script for target "(,drone)" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 237: warning: using previous script for "(,drone)" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 248: Need an operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 256: Missing dependency operator
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 257: warning: duplicate script for target "ifeq" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 8: warning: using previous script for "ifeq" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 257: warning: duplicate script for target "(,drone)" ignored
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 237: warning: using previous script for "(,drone)" defined here
make: "/root/go/src/code.gitea.io/gitea/Makefile" line 258: Need an operator
make: Fatal errors encountered -- cannot continue
make: stopped in /root/go/src/code.gitea.io/gitea

var 2
root@web:~ # pkg install gitea
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        gitea: 1.3.3
        bash: 4.4.19
*********************************************************
===> Creating groups.
Creating group 'git' with gid '211'.
===> Creating users
Creating user 'git' with uid '211'.
[web] [2/2] Extracting gitea-1.3.3: 100%
root@web:~ # gitea web
2018/03/21 09:47:11 [W] Custom config '/usr/local/sbin/custom/conf/app.ini' not found, ignore this if you're running first time
2018/03/21 09:47:11 [T] AppPath: /usr/local/sbin/gitea
2018/03/21 09:47:11 [T] AppWorkPath: /usr/local/sbin
2018/03/21 09:47:11 [T] Custom path: /usr/local/sbin/custom
2018/03/21 09:47:11 [T] Log path: /usr/local/sbin/log
2018/03/21 09:47:11 [I] Gitea v1.3.3
2018/03/21 09:47:11 [I] Log Mode: Console(Trace)
2018/03/21 09:47:11 [I] XORM Log Mode: Console(Trace)
2018/03/21 09:47:11 [I] Cache Service Enabled
2018/03/21 09:47:11 [I] Session Service Enabled
2018/03/21 09:47:11 [I] SQLite3 Supported
2018/03/21 09:47:11 [I] Run Mode: Development
panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory

goroutine 1 [running]:
code.gitea.io/gitea/vendor/github.com/go-macaron/i18n.initLocales(0xc420277375, 0x0, 0x1147c23, 0xb, 0xc42025bf80, 0x1153169, 0x12, 0xc420104c60, 0x15, 0x15, ...)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/vendor/github.com/go-macaron/i18n/i18n.go:57 +0x764
code.gitea.io/gitea/vendor/github.com/go-macaron/i18n.I18n(0xc4202840c0, 0x1, 0x1, 0x0, 0x0)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/vendor/github.com/go-macaron/i18n/i18n.go:158 +0xcb
code.gitea.io/gitea/routers/routes.NewMacaron(0xc420247e00)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/routers/routes/routes.go:93 +0x6ef
code.gitea.io/gitea/cmd.runWeb(0xc420247e00, 0x0, 0x0)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/cmd/web.go:67 +0xb2
code.gitea.io/gitea/vendor/github.com/urfave/cli.HandleAction(0xfc6800, 0x118e9b8, 0xc420247e00, 0xc42008d500, 0x0)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:471 +0xad
code.gitea.io/gitea/vendor/github.com/urfave/cli.Command.Run(0x113bc7c, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1159519, 0x16, 0x0, ...)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/command.go:191 +0xa0e
code.gitea.io/gitea/vendor/github.com/urfave/cli.(*App).Run(0xc42009f1e0, 0xc4200b0000, 0x2, 0x2, 0x0, 0x0)
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:241 +0x5b8
main.main()
        /wrkdirs/usr/ports/www/gitea/work/src/code.gitea.io/gitea/main.go:48 +0x383

how install gitea on FreeBSD?

sysrc gitea_enable=YES
service gitea start
but i have such a problem
root@web:confused: # service gitea start
daemon: illegal option -- S
usage: daemon [-cfr] [-p child_pidfile] [-P supervisor_pidfile]
[-t title] [-u user] command arguments ...

gitea_start() {
        /usr/sbin/daemon -S -l ${gitea_facility} -s ${gitea_priority} -t ${name} \
                -u ${gitea_user} -p ${pidfile} \
                /usr/bin/env -i \
                "GITEA_WORK_DIR=${gitea_shared}" \
                "GITEA_CUSTOM=/usr/local/etc/${name}" \
                "HOME=${githome}" \
                "PATH=/usr/local/bin:${PATH}" \
                "USER=git" \
                $command

tags -S -l -s illegal for FreeBSD
root@web:/ # service gitea start
root@web:/ # 2018/03/21 13:32:03 [T] AppPath: /usr/local/sbin/gitea
2018/03/21 13:32:03 [T] AppWorkPath: /usr/local/share/gitea
2018/03/21 13:32:03 [T] Custom path: /usr/local/etc/gitea
2018/03/21 13:32:03 [T] Log path: /var/log/gitea
2018/03/21 13:32:03 [I] Gitea v1.3.3
2018/03/21 13:32:15 Serving 127.0.0.1:3000 with pid 94434

but is don't work i could not connect to ip_address:3000

change ip addres in app.ini to 0.0.0.0 and it work


text:
Provide reproductible binary (if possible)

To ease the validation process in case of potential corruption.
For information: https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/
Related #4167

Seems like this should be fixed by: https://github.com/go-gitea/gitea/pull/18193#pullrequestreview-846150669

authors: Gusted sapk


text:
Slight performance changes to integrations/git_test.go

Stop cloning the large repos in the push-to-create test - they unnecessarily slow for testing this feature which does not need them
Stop using crypto/rand for generating the data in the commits - pseudo random is sufficient - and stop creating 128Mb buffers in memory.

Gain around 3-5min (better than nothing)


text:
Improve trace logging for pulls and processes

Our trace logging is far from perfect and is difficult to follow.
This PR:

Add trace logging for process manager add and remove.
Fixes an errant read file for git refs in getMergeCommit
Brings in the pullrequest String and ColorFormat methods introduced in #22568
Adds a lot more logging in to testPR etc.

Ref #22578

Codecov Report

Merging #22633 (34db05d) into main (cc1f8cb) will decrease coverage by 0.18%.
The diff coverage is 47.83%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main   #22633      +/-   ##
==========================================
- Coverage   48.22%   48.04%   -0.18%
==========================================
  Files        1050     1059       +9
  Lines      142937   144417    +1480
==========================================
+ Hits        68925    69388     +463
- Misses      65772    66746     +974
- Partials     8240     8283      +43

Impacted Files
Coverage Δ

models/auth/token.go
45.18% <ø> (ø)

models/git/lfs.go
17.37% <0.00%> (-3.96%)
:arrow_down:

models/issues/issue_project.go
31.29% <0.00%> (+0.23%)
:arrow_up:

models/organization/team.go
58.00% <ø> (-7.45%)
:arrow_down:

models/organization/team_user.go
66.66% <ø> (-7.91%)
:arrow_down:

models/packages/package_blob.go
50.00% <0.00%> (-6.82%)
:arrow_down:

models/repo/repo_list.go
74.29% <0.00%> (-0.17%)
:arrow_down:

models/system/setting.go
53.80% <0.00%> (-2.13%)
:arrow_down:

models/user.go
38.33% <0.00%> (+3.21%)
:arrow_up:

models/webhook/webhook.go
77.60% <ø> (+10.17%)
:arrow_up:

... and 117 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

I tried to backport but had merge conflicts

authors: codecov-commenter yardenshoham zeripath


text:
Mention completion for issue editor.

Mention completion on issue editor.  @mention engine from tribute.
Demo:
New issue:

View/Edit issue:

Codecov Report

Merging #3136 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3136      +/-   ##
==========================================
+ Coverage   34.83%   34.87%   +0.03%
==========================================
  Files         275      275
  Lines       40028    40030       +2
==========================================
+ Hits        13945    13960      +15
+ Misses      24085    24068      -17
- Partials     1998     2002       +4

Impacted Files
Coverage Δ

routers/repo/issue.go
31.9% <100%> (+0.12%)
:arrow_up:

models/repo.go
41.28% <0%> (-0.19%)
:arrow_down:

models/repo_list.go
67.18% <0%> (+1.56%)
:arrow_up:

modules/indexer/repo.go
63.47% <0%> (+2.6%)
:arrow_up:

models/repo_indexer.go
54.85% <0%> (+5.33%)
:arrow_up:

Continue to review full report at Codecov.

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

Can you convert tribute css to less file and include into main gitea css? Then there would be no need for additional css include

@lafriks I will check out later, but I see other JS plugin's css also included by this way.

@ethantkoenig Done.

@harryxu yes I know, this one has small css so it was just an idea, it's totally not required and not blocking this PR

LGTM

LGTM

authors: codecov-io ethantkoenig harryxu lafriks lunny


text:
Added tags pull step to drone config to show correct version hashes i…

As title.

Tags are apparently pulled correctly, so proper versions should work now. Though I'm not quite sure how to test this since it needs a release...

Damn I don't think it works (from the first build log):
GO111MODULE=on go build -mod=vendor -i -v -tags 'bindata sqlite sqlite_unlock_notify' -ldflags '-s -w -X "main.MakeVersion=GNU Make 4.1" -X "main.Version=a96318d30" -X "main.Tags=bindata sqlite sqlite_unlock_notify"' -o gitea

From the build command, it appers to work now: https://drone.gitea.io/go-gitea/gitea/8634/1/10
GO111MODULE=on go build -mod=vendor -i -v -tags 'bindata sqlite sqlite_unlock_notify' -ldflags '-s -w -X "main.MakeVersion=GNU Make 4.1" -X "main.Version=1.9.0+dev-192-g6fbf87d2d" -X "main.Tags=bindata sqlite sqlite_unlock_notify"' -o gitea

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@26c7c97). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #6836   +/-   ##
=========================================
  Coverage          ?   41.22%
=========================================
  Files             ?      421
  Lines             ?    58120
  Branches          ?        0
=========================================
  Hits              ?    23959
  Misses            ?    30989
  Partials          ?     3172

Continue to review full report at Codecov.

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

Please send backport to 1.8

Does this fix https://github.com/go-gitea/gitea/issues/6806 ?

Well it depends on what they mean by a stable output

But yes things should now have 1.9.0+dev prefixed and similarly for 1.8

It should also fix https://github.com/go-gitea/gitea/issues/4782 as on the tag the version is good event without the DRONE_TAG set :
/go/src/code.gitea.io/gitea # git checkout v1.8.0
HEAD is now at 799f5e05c 1.8.0 Changelog (#6678)
/go/src/code.gitea.io/gitea # git describe --tags --always | sed 's/-/+/' | sed 's/^v//'
1.8.0

Backport is up:  #6840

authors: codecov-io kolaente sapk zeripath


text:
Prevent lfs process filter from running

This PR sets the lfs process filter to empty preventing them from running during merge.
Fixes #732

Codecov Report

Merging #7062 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #7062      +/-   ##
==========================================
- Coverage   41.46%   41.44%   -0.02%
==========================================
  Files         442      442
  Lines       59611    59623      +12
==========================================
- Hits        24715    24711       -4
- Misses      31665    31679      +14
- Partials     3231     3233       +2

Impacted Files
Coverage Δ

models/pull.go
49.15% <0%> (-0.57%)
:arrow_down:

models/unit.go
62.16% <0%> (-5.41%)
:arrow_down:

models/repo_list.go
72.08% <0%> (-1.02%)
:arrow_down:

routers/repo/view.go
42.02% <0%> (-1.02%)
:arrow_down:

modules/log/file.go
77.62% <0%> (+2.09%)
:arrow_up:

modules/log/colors_router.go
87.5% <0%> (+4.16%)
:arrow_up:

Continue to review full report at Codecov.

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

Hmm... I think this might not be the correct solution. We need to tell the LFS that the merged files are now being referenced in the merged into repository - and without these filters running, at least in some way, this won't happen.

Therefore I believe this PR is ready for merging.

Damn! I'm going to have to rewrite the git tests because we actually want git to run normally for these.

I'm going to close this whilst I rethink

authors: codecov-io zeripath


text:
Unescape wiki filename string (Fixes #8284)

This pull request allows wiki pages with special characters in the title to be accessed. It does this by passing the wiki name through html.UnescapeString() when looking for the filename.
Fixes https://github.com/go-gitea/gitea/issues/8284

Hmm... This build on my machine. I'll have to figure out what I did wrong to make the test build fail... Sorry about that

Well, now I'm not too sure what... Maybe someone has a suggestion

It's failing the unit test TestEditWikiPost():

Are you able to run that test it in your computer?

You can test it yourself using:
cd routers/repo
go test -tags="sqlite sqlite_unlock_notify" -run TestEditWikiPost

Or even better:
TAGS="sqlite sqlite_unlock_notify" make clean generate test

(that would run all unit tests, but not the integration tests).

@guillep2k Thanks for the tip!
I think I've worked out a better solution. Basically the issue is that when WikiNameToFilename() passes the name through url.QueryEscape(), it actually no longer matches the filename in cases where there are special characters in the name. But the unit test has a fit when it's not there. So I added url.QueryUnescape() to wikiContentsByName() to correct any special characters later so that these pages can be accessed.

Codecov Report

Merging #8374 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #8374      +/-   ##
==========================================
- Coverage    41.8%   41.79%   -0.01%
==========================================
  Files         496      496
  Lines       65586    65586
==========================================
- Hits        27416    27414       -2
- Misses      34654    34657       +3
+ Partials     3516     3515       -1

Impacted Files
Coverage Δ

routers/repo/wiki.go
40.88% <100%> (ø)
:arrow_up:

models/unit.go
62.16% <0%> (-5.41%)
:arrow_down:

routers/repo/view.go
42.53% <0%> (-1.02%)
:arrow_down:

models/repo_list.go
74.14% <0%> (+0.97%)
:arrow_up:

modules/log/event.go
65.64% <0%> (+1.02%)
:arrow_up:

Continue to review full report at Codecov.

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

I'm so sorry, I've kind of made a mess in this PR lol... I'm a noob. But at least I'm learning lots!
My build seems to have finished... Just waiting for the notify.

No worries.
Now your PR passes the tests, but the CI got stuck on 'notify'. Somebody will look into that.

@Tekaoh could you add a unit test?

@lunny I wouldn't know how, or even really what that means lol... I just took a try at fixing the bug I found. My commit fixes it, but I'm not entirely sure about all the correct procedures...

@Tekaoh You can find many example on https://github.com/go-gitea/gitea/blob/master/models/wiki_test.go#L33 and I think it's not complicated.

I did some deeper digging and found that this PR is not going to be a good solution. I am therefore going to just close it for now.
Maintainers: Please see my explanation at https://github.com/go-gitea/gitea/issues/8284#issuecomment-538779094 and perhaps consider weighing in on what you think should be done. Thanks!

authors: Tekaoh codecov-io guillep2k lunny


text:
silence fomantic error regarding tabs

Fomantic expects all tabs to have a target element with content as defined by the data-tab attribute. All our usage of the tab module seems to use <a> element tabs that link to new pages so these content elements are never present and fomantic complains about that in the console with
an "Activated tab cannot be found" error. This silences that error.
Ref: https://fomantic-ui.com/modules/tab.html
Errors can be seen in the browser console on every page containing those link-style tabs, for example https://try.gitea.io/silverwind/symlink-test.

@silverwind please send a backport to v1.11 if possible.

backport in https://github.com/go-gitea/gitea/pull/9718

authors: sapk silverwind


text:
mysql scan rows to map[string]interface,type DECIMAL is string #4466

GORM Other Playground Link
https://github.com/go-gorm/playground/pull/337
mysql: scan rows to map[string]interface,type DECIMAL is string and is wrong
If you know the table structure and define the structure, the data will be printed correctly. But if the table structure is unknown,then the data will be printed incorrectly.
defer rows.Close()
columns, err := rows.Columns()
if err != nil {
return nil, err
}
numColumns := len(columns)
values := make([]interface{}, numColumns)
for i := range values {
values[i] = new(interface{})
}
var results []map[string]interface{}
for rows.Next() {
	if err := rows.Scan(values...); err != nil {
		return nil, err
	}

	dest := make(map[string]interface{}, numColumns)
	for i, column := range columns {
		fmt.Println(reflect.TypeOf(values[i]))
		fmt.Println(values[i].(*interface{}))
		fmt.Println(*values[i].(*interface{}))
		dest[column] = values[i]
	}
	//fmt.Println("=====")
	//fmt.Println(dest)
                 //print: 1234.5677 right
                 //print: NzMxLjI= wrong
	results = append(results, dest) //ps: NzMxLjI=
}

if err := rows.Err(); err != nil {
	return nil, err
}
return results, nil

gorm.io/gorm v1.24.0

@a631807682 I am not sure if this helps. See the comments.
https://github.com/go-sql-driver/mysql/issues/1401

@a631807682 I am not sure if this helps. See the comments.
go-sql-driver/mysql#1401

When we specialize the scan method for one type of a driver, it means that we start to specify the scan method for all types of all drivers, because each databasetype is handled differently by different drivers, and they may even use Scanner to dynamically allocate the type (e.g. clickhouse).
It's not that we can't do it, it's just that we pay enough for it and not enough of the benefit.

AFAIK, only the mysql driver that we are using has this issue. I am the author of the following packages. I work with all kinds of drivers, and found no other drivers having such problem.
https://github.com/elgs/gosqljson
https://github.com/elgs/gosqlapi

repo: go-gorm/gorm


text:
Interface to assign ID with a query after insert (like OracleDialect)

Hi, I noticed that in the former version of Oracle Dialect the automatic fetch of a generate id was missing.
I created a new Interface for the purpose: TargetQueryInserter
Here is an Example of usage:
var obj struct {
	Id int64
}
var t = dbMap.AddTable(obj)
t.SetKeys(true, "Id")
t.ColMap("Id").GeneratedIdQuery = "SELECT sequence.currval FROM DUAL"

Can the TargetQueryInserter be an unexpored interface? I don't think it adds value to the exported API.

Merged it anyway. Chances are that the dialects are moved to their own packages (#272) so the dialect interface (and friends) need to be exported anyway.

Thanks :+1:

authors: GeertJohan klaidliadon

repo: go-gorp/gorp


text:
COM_BINLOG_DUMP_GTID.  parseBinlogDumpGTID  panic

the data is come from mysql 5.7
buf = []byte{
0, 0, 139, 166, 51, 123, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 88, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 21, 68, 55, 139, 177, 143, 17, 237, 142, 55, 228, 61, 26, 94, 128, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 57, 71, 212, 82, 0, 0, 0, 0, 99, 24, 112, 68, 150, 11, 17, 237, 162, 244, 92, 111, 105, 46, 160, 132, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 189, 235, 27, 2, 0, 0, 0, 0,
}
mysql can parse the data correctly, but parseBinlogDumpGTID will panic
command.go:
gtidSet, err := parseBinlogDumpGTID(data)

func parseMysqlGtidDumpPacket(data []byte) (*mysql.MysqlGTIDSet, uint32, error) {
var flags uint16
var dataSize uint32
var slaveServerID uint32
var binlogFileNameSize uint32
var binlogFileName string
var binlogPos uint64
var pos uint32
flags = binary.LittleEndian.Uint16(data[pos:])
pos += 2

slaveServerID = binary.LittleEndian.Uint32(data[pos:])
pos += 4

binlogFileNameSize = binary.LittleEndian.Uint32(data[pos:])
pos += 4

binlogFileName = string(data[pos : pos+binlogFileNameSize])
pos += binlogFileNameSize

binlogPos = binary.LittleEndian.Uint64(data[pos:])
pos += 8

dataSize = binary.LittleEndian.Uint32(data[pos:])
pos += 4

//only support mysql gtid
slaveGtidExecuted, err := mysql.DecodeMysqlGTIDSet(data[pos:])
if err != nil {
	log.Errorf("DecodeMysqlGTIDSet error,err:%s,data:%v", err, data[pos:])
	return nil, 0, err
}

log.Debugf("handleBinlogDumpGtid:flag:%d,slaveServerID:%d,binlogFileNameSize:%d,"+
	"binlogFileName:%s,binlogPos:%d,dataSize:%d,slaveGtidExecuted:%v", flags, slaveServerID, binlogFileNameSize,
	binlogFileName, binlogPos, dataSize, *slaveGtidExecuted)
return slaveGtidExecuted, slaveServerID, nil

}

I see your screenshot, this is not the commit hash in our repo.

Because I added logs

Because I added logs @lance6716

Please find that package (jedplus/go-mysql-org) and find

which version of this package (go-mysql-org/go-mysql) does it use. (Maybe we have fixed the bug in later version?)
produce a way to reproduce the problem

@lance6716
func parseBinlogDumpGTID(data []byte) (*mysql.MysqlGTIDSet, error) {
if len(data) < 15 {
return nil, mysql.ErrMalformPacket
}
lenPosName := binary.LittleEndian.Uint32(data[11:15])
if len(data) < 22+int(lenPosName) {
return nil, mysql.ErrMalformPacket
}
return mysql.DecodeMysqlGTIDSet(data[22+lenPosName:])

}
in v1.9.1    Slice index 11-15 seems wrong, I think it is 6-10

Please provide a way to reproduce the problem using official MySQL binaries. I think the binlog content is not standard, is this a customized MySQL RDS that generate wrong binlog?

It might help to do a network trace and load that in Wireshark to see how it decodes these bytes.

authors: dveeden goooooooooooooood lance6716

repo: go-mysql-org/go-mysql


text:
oneof support float

Package version eg.  v10:
Issue, Question or Enhancement:
json.Unmarshal value is map[string]interface number will be float64, so i want oneof can support float whitout fractional
Code sample, to showcase or reproduce:
func isOneOf(fl FieldLevel) bool {
	vals := parseOneOfParam2(fl.Param())

	field := fl.Field()

	var v string
	switch field.Kind() {
	case reflect.String:
		v = field.String()
	case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
		v = strconv.FormatInt(field.Int(), 10)
	case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64:
		v = strconv.FormatUint(field.Uint(), 10)
	case reflect.Float32, reflect.Float64:
		v = decimal2String(field.Float())

	default:
		panic(fmt.Sprintf("Bad field type %T", field.Interface()))
	}
	for i := 0; i < len(vals); i++ {
		if vals[i] == v {
			return true
		}
	}
	return false
}
func decimal2String(f float64) string {
	_, frac := math.Modf(f)
	if frac != 0 {
		panic(fmt.Sprintf("The float %v has a fractional part of %v.\n", f, frac))
	}
	return strconv.FormatFloat(f, 'f', 0, 64)
}

To modify the code and make it support float values without fractions, you can update the decimal2String function to round the float value instead of throwing a panic when there is a fractional part. Here's an updated version of the function:
func decimal2String(f float64) string {
	rounded := math.Round(f)
	return strconv.FormatFloat(rounded, 'f', 0, 64)
}

By using the math.Round function, the float value will be rounded to the nearest integer. This way, when converting the float to a string, you'll have the desired behavior of supporting float values without fractional parts.

authors: LjtGentle alirezakazemeini

repo: go-playground/validator


text:
Update changelog for v9

It is not a full list of changes, but it should be a good start

Yes, we record important changes in CHANGELOG.md, for more trivial, we can record in Releases of each version.

repo: go-redis/redis


text:
Tegola viewer not showing tiles for WebMercator

I'm using a mvt_postgis provider with default srid 3857. Everything works fine I my custom OpenLayers viewer shows the vector tiles as expected.
But the internal Tegola viewer doesn't. Is there any way to change the viewer srid or does it only work with 4326 projections? Or could it be a problem with the style automatically generated by the built in viewer?

Can you provide a few more details? your tegola config and the tegola version would be helpful.

I'm using Tegola v0.13.0. The config file looks something like that:
[webserver]
port = ":8080"

# register data providers
[[providers]]
name = "map"            # provider name is referenced from map layers
type = "mvt_postgis"    # the type of data provider. currently only supports postgis
host = "192.168.1.0"    # postgis database host
port = 5432             # postgis database port
database = "***"        # postgis database name
user = "***"            # postgis database user
password = "***"        # postgis database password

  [[providers.layers]]
  name = "bus"
  geometry_fieldname = "geom"
  id_fieldname = "id"
  geometry_type = "LineString"
  sql = "SELECT ST_AsMVTGeom(geom,!BBOX!) AS geom, name, id FROM mobility.bus WHERE geom && !BBOX!"

[[maps]]
name = "ctbb"
center = [1.9, 41.5, 12.0] # set the center of the map

  [[maps.layers]]
  provider_layer = "map.bus"
  min_zoom = 10
  max_zoom = 20

[cache]
type = "file"
basepath = "/tmp/tegola"

@geraldo thanks for the response, and sorry for the slow responses on my end. I have been on paternity leave, hanging with my new son!
the ST_AsMVTGeom function is expecting the geom data to be in 3857. If the data is not in 3857 then it will need to be reprojected. As far as the internal viewer not showing this data, but OpenLayers is, that's kind of odd. Are you sure the map is in the correct position? Is there anyway I can access the dataset to test?

@ARolek Congratulations on your son!
I couldn't make ST_AsMVTGeom() work using a reprojection, but I'll hace another look on that shortly. The geometry is saved as EPSG:25831 in Postgis.
Right now it works fine using this layer definition in Openlayers:

new ol.layer.VectorTile({
  source: new ol.source.VectorTile({
    format: new ol.format.MVT(),
    tileGrid: ol.tilegrid.createXYZ({maxZoom: 20}),
    tilePixelRatio: 16,
    url:'http://localhost:8080/maps/ctbb/ctbb.bus_l66_parades/{z}/{x}/{y}.vector.pbf',
    projection: new ol.proj.Projection({
      code: 'EPSG:25831',
      units: 'm',
    });
  }),
}),

@geraldo Thank you!
Ok, so this makes sense. ST_AsMVTGeom does expect the geometries to be in 3857. I documented how you can perform this transformation at query time here. When you apply this change, your Open Layers config will not need the projection config.
Let me know if this works for you

I changed these parameters in Tegola config file:
srid = 25831 sql = "SELECT ST_AsMVTGeom(ST_Transform(geom, 3857),ST_Transform(!BBOX!,3857)) AS geom, name, id FROM mobility.bus WHERE geom && !BBOX!"
I get this error:
[ERROR] handle_map_layer_zxy.go:165: error marshalling tile: Error trying to convert tile point: don't know how to convert from 25831 to 3857
A had a look on the projection issues, but can't figure out how to include EPSG:28831 projection (through proj4?).

@geraldo I'm not familiar with that projection. If you know the proj details, it looks like you can add a custom projection to PostGIS. Note, you're going to need to reproject the !BBOX! tokens as well.

@geraldo I'm going to close this issue for now. Please feel free to reopen it if you have more details. It would be great to know if the custom projection suggestion I provided helps.

authors: ARolek geraldo

repo: go-spatial/tegola


text:
Question: How to trim all model's strings before validation

Hello,
i'm trying to find a way to trim all strings before the server validate the model, so the validation failed if the user set only white spaces in a string.
Any idea how to do that ?

Seems like you would need to add a pattern on each string, since even an empty string is enough to satisfy the required attribute.

@BertrandGouny I had the very same issue and adopted what Greg is now saying:
 pattern: "^\\S.*\\S$"
Before that, I simply trimmed the parameter at the beginning of my operation, with strings.TrimSpace() and handled the error manually (e.g. sending back a 40x error etc...).

My case was to avoid leading or trailing blanks, so your regexp would be different. But you see the idea.

Perhaps something like  '^.*\\S.*$'  ... (at least one non-blank)

Thanks you @gregmarr and @fredbi
using a pattern will do the trick indeed  :+1:
i ended up with something like ^(\S.*\S|\S)*$ to accept only trimmed strings and single non-whitespace char.
Feel free to close this :)

you close it. That's the policy in this house, man... 👍

authors: BertrandGouny fredbi gregmarr

repo: go-swagger/go-swagger


text:
Symbol pd_commnand_callback_t contains spelling typo

Symbol pd_commnand_callback_t needs to be renamed to pd_command_callback_t to fix spelling typo.

I already have a fix for this, but I'm unable to assign myself to the ticket.  When I try to push the branch, it gives me a permission denied error.
$ git push --set-upstream origin symbol_typo_fix
remote: Permission to goToMain/libosdp.git denied to pcpro178.
fatal: unable to access 'https://github.com/goToMain/libosdp/': The requested URL returned error: 403

Hah, I was about to point this out too.

I'm going to fix this myself and add you as the reporter.

Fixed in a7913ba5

repo: goToMain/libosdp


text:
#191 [VM Part] Add Negative Index Support for Array API Method

Negative index support for Array#[], Array#[]= and Array#at

@Maxwell-Alexius GJ!

repo: goby-lang/goby


text:
Cancel process need execute cancel command before kill build process

So that user have a chance to gracefully stop the build process

@wpc do we run all parent commands' cancel tasks before killing the exec command sub process too?

yes

without killing subprocess, how could a custom clean-up script really clean-up the working directory? Because subprocess will continue to output data or hold file handler when you tried to clean up something in directory.
and when we say "gracefully stop the build process", is there really a "gracefully stop" for most of builds?

authors: wpc xli

repo: gocd-contrib/gocd-golang-agent


text:
explain two issues that tripped me up for hours

the need to pub ldaps://xxxx in the URL when you need an ldaps connection is not obvious for for admins who dont setup ldaps/starttls all day. What makes this worse is the deprecated (?) starttls setting in the cruise-config.xml that appears to do the same thing... hence i just assumed that i was requesting ldap over tls until i went and read some of the code...
The second change in the docs is regarding the debug. the line in the gocd server base docker image
GOCD_SERVER_JVM_OPTS+=("-Dgo.console.stdout=true")

which gets added into the wrapper-properties.conf after boot time as:
wrapper.java.additional.100=-Dgo.console.stdout=true

so obviously this conflicts with any other entries with index100 and caused debugging to not work until i discovered it..

Thanks for the PR. Will try and get some time to look at this. I'm not an expert with ldaps/starttls either :)
Are you able to help me understand where the existing entry with index 100 came from in your case? Depending on which mechanism toy are using to run GoCD (docker, helm, one of the installers) there are some different mechanisms by which it tries to help automatically add properties.

sure no worries!
it's this one here in the gocd server docker image for stdout that is set by default at index 100
https://github.com/gocd/docker-gocd-server/blob/master/docker-entrypoint.sh#L94-L101
but the user could easily set more jvm opts here with indexes that conflict with whatever is set in the wrapper-properties.conf
maybe the docker-gocd-server people could agree to start their indexes above 200...

I think the idea is that if you are using the docker images, your custom stuff should be added to GOCD_SERVER_JVM_OPTS in a single place and the image's container entrypoint will manage splitting the string and updating the wrapper properties and indexes for you via https://github.com/gocd/docker-gocd-server/blob/861fdd0afc6cdb66e4546c523f3c689dfaca1401/docker-entrypoint.sh#L90-L101
IIRC I don't think it's intended that you mount your own wrapper-properties.conf over the top, or underneath the one the image is trying to manage for you.

authors: caljnj chadlwilson

repo: gocd/gocd-ldap-authentication-plugin


text:
creature's mouth sometimes stays visible after creature dies

Modify the death animation to hide the mouth

added $AnimationPlayer.stop() to die() in creature.tscn


text:
Have an option to export a bitmask variable.

Godot version:
Godot 3.0.2
Issue description:
What I'm requesting is a way to export a bitmask with labeled names from a script. What I want to be able to do is something like this
export("Basic", "Fire", "Ice", "Electric") var weakness

And be able to check or uncheck any of those names to create a bit mask. It could look something like the bitmask that physics layers and render layers have, except only have the options specified in the export.

And the actual variable would be an integer, so I can then do something like
if weakness & damage_type:
    damage_value *= 2.0

This should work (docs):
export(int, FLAGS, "Basic", "Fire", "Ice", "Electric") var weakness

Oooh, yes, that is what I wanted. I completely missed that because I was only looking at all the export examples which were directly above that bit flag section. And none of my googling found any mention of it probably because I was searching "bitmask" instead of "bit flag".

authors: CowThing bojidar-bg

repo: godotengine/godot


text:
3.0.6 + Mono 5.12 Crashes on Mac

Godot version:

3.0.6
OS/device including version:

macOS 10.13.6
Issue description:

I have version 3.0.6 + Mono 5.12 installed on my Mac and anytime I try to use C# for a script with an external editor Godot crashes and closes.  The terminal doesn't print anything. macOS shows a dialog saying Godot has quit unexpectedly.
It seems related to using an external editor (either VSCode or MonoDevelop). If I turn that off and click the script it loads within the Godot script editor, but when the external editor it set, that's when the crash occurs.
FWIW, I do not experience this issue on Windows.
macOS Crash Dump
(notice that the dump says 3.0.5 even though the Godot UI says 3.0.6)
Process:               Godot [73926]
Path:                  /Applications/Godot_mono.app/Contents/MacOS/Godot
Identifier:            Godot
Version:               3.0.5 (3.0.5)
Code Type:             X86-64 (Native)
Parent Process:        Godot [73922]
Responsible:           Godot [73926]
User ID:               501

Date/Time:             2018-08-20 11:35:42.307 -0400
OS Version:            Mac OS X 10.13.6 (17G65)
Report Version:        12
Anonymous UUID:        EBEE927E-5B72-D605-1215-A7069FD201A9

Sleep/Wake UUID:       09DF4D81-EB7E-4C9E-BB26-8ADA7C805AC1

Time Awake Since Boot: 500000 seconds
Time Since Wake:       69000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
*** multi-threaded process forked ***
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff6392ab66 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff63af5080 pthread_kill + 333
2   libsystem_c.dylib             	0x00007fff638861ae abort + 127
3   org.godotengine.godot         	0x00000001008f181c mono_handle_native_crash + 636
4   libsystem_platform.dylib      	0x00007fff63ae8f5a _sigtramp + 26
5   ???                           	000000000000000000 0 + 0
6   libsystem_c.dylib             	0x00007fff638861ae abort + 127
7   org.godotengine.godot         	0x000000010129346d OS_Unix::execute(String const&, List<String, DefaultAllocator> const&, bool, long long*, String*, int*, bool) + 2109
8   org.godotengine.godot         	0x0000000100e28a4b GodotSharpEditor::open_in_external_editor(Ref<Script> const&, int, int) + 1771
9   org.godotengine.godot         	0x00000001019dbf17 ScriptEditor::edit(Ref<Script> const&, int, int, bool) + 279
10  org.godotengine.godot         	0x00000001019ffe77 ScriptEditorPlugin::edit(Object*) + 167
11  org.godotengine.godot         	0x00000001015330f2 EditorNode::_edit_current() + 4082
12  org.godotengine.godot         	0x0000000101523cfe EditorNode::_resource_selected(Ref<Resource> const&, String const&) + 46
13  org.godotengine.godot         	0x0000000101523c61 EditorNode::edit_resource(Ref<Resource> const&) + 49
14  org.godotengine.godot         	0x000000010172a879 SceneTreeDock::_script_open_request(Ref<Script> const&) + 41
15  org.godotengine.godot         	0x0000000101745d4e MethodBind1<Ref<Script> const&>::call(Object*, Variant const**, int, Variant::CallError&) + 318
16  org.godotengine.godot         	0x00000001028f54ee Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 414

(notice that the dump says 3.0.5 even though the Godot UI says 3.0.6)

@hpvb Remember that you need to bump the hardcoded version strings in misc/dist/osx_tools.app/Contents/Info.plist when making a new release.

authors: akien-mga toddgibson