github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-13 11:31:28 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

1.18.0 on Windows error: can not resolve localhost, ! [remote rejected] master -> master (pre-receive hook declined) #10070

New Issue
Closed
opened 2025-11-02 08:57:22 -06:00 by GiteaMirror · 28 comments
GiteaMirror commented 2025-11-02 08:57:22 -06:00
Owner
Copy Link

Originally created by @jinyangcruise on GitHub (Jan 8, 2023).

Description

Save your time:

1.17.4 is good but 1.18.0 has a bug: 
dial tcp: lookup localhost on 114.114.114.114:53: no such host

Detailed:

I use 1.18.0 Gitea, when I push files, occur:

$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 20 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 305 bytes | 305.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Gitea: Internal Server Error
remote: Unable to contact gitea: Post "http://localhost:3000/api/internal/hook/pre-receive/jinyang/test": dial tcp: lookup localhost on 114.114.114.114:53: no such host
To http://localhost:3000/jinyang/test.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'http://localhost:3000/jinyang/test.git'

I searched some related issues but finally failed to fix this.

Then I installed 1.17.4 Gitea and this problem gone.

Then I re-installed 1.18.0 Gitea again and still can not push.

Gitea Version

1.18.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

NA

Git Version

git version 2.39.0.windows.2

Operating System

WINDOWS 11

How are you running Gitea?

download binary on https://dl.gitea.io/gitea
[gitea-1.18.0-windows-4.0-amd64.exe]

download it on my PC and move it to D:\Program Files\Gitea, then double click the gitea-1.18.0-windows-4.0-amd64.exe

Database

SQLite

Originally created by @jinyangcruise on GitHub (Jan 8, 2023). ### Description Save your time: ``` 1.17.4 is good but 1.18.0 has a bug: dial tcp: lookup localhost on 114.114.114.114:53: no such host ``` Detailed: I use 1.18.0 Gitea, when I push files, occur: ``` $ git push Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 20 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 305 bytes | 305.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Gitea: Internal Server Error remote: Unable to contact gitea: Post "http://localhost:3000/api/internal/hook/pre-receive/jinyang/test": dial tcp: lookup localhost on 114.114.114.114:53: no such host To http://localhost:3000/jinyang/test.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'http://localhost:3000/jinyang/test.git' ``` I searched some related issues but finally failed to fix this. Then I installed 1.17.4 Gitea and this problem gone. Then I re-installed 1.18.0 Gitea again and still can not push. ### Gitea Version 1.18.0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots NA ### Git Version git version 2.39.0.windows.2 ### Operating System WINDOWS 11 ### How are you running Gitea? download binary on https://dl.gitea.io/gitea [gitea-1.18.0-windows-4.0-amd64.exe] download it on my PC and move it to D:\Program Files\Gitea, then double click the gitea-1.18.0-windows-4.0-amd64.exe ### Database SQLite
GiteaMirror added the type/bug label 2025-11-02 08:57:22 -06:00
GiteaMirror commented 2025-11-02 08:57:23 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 8, 2023):

Could you ping localhost?

@lunny commented on GitHub (Jan 8, 2023): Could you `ping localhost`?
GiteaMirror commented 2025-11-02 08:57:23 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jan 8, 2023):

Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost

@wxiaoguang commented on GitHub (Jan 8, 2023): Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost
GiteaMirror commented 2025-11-02 08:57:23 -06:00
Author
Owner
Copy Link

@jinyangcruise commented on GitHub (Jan 9, 2023):

Could you ping localhost?

yes

@jinyangcruise commented on GitHub (Jan 9, 2023): > Could you `ping localhost`? yes
GiteaMirror commented 2025-11-02 08:57:23 -06:00
Author
Owner
Copy Link

@jinyangcruise commented on GitHub (Jan 9, 2023):

Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost

I can't find a LOCAL_ROOT_URL in app.ini, should I add it at somewhere?

@jinyangcruise commented on GitHub (Jan 9, 2023): > Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost I can't find a LOCAL_ROOT_URL in app.ini, should I add it at somewhere?
GiteaMirror commented 2025-11-02 08:57:23 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 9, 2023):

Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost

I can't find a LOCAL_ROOT_URL in app.ini, should I add it at somewhere?

Please check the documentation.

@lunny commented on GitHub (Jan 9, 2023): > > Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost > > I can't find a LOCAL_ROOT_URL in app.ini, should I add it at somewhere? Please check the documentation.
GiteaMirror commented 2025-11-02 08:57:23 -06:00
Author
Owner
Copy Link

@jinyangcruise commented on GitHub (Jan 9, 2023):

Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost

I can't find a LOCAL_ROOT_URL in app.ini, should I add it at somewhere?

Please check the documentation.

Thank you very much! Success!

By the way, english version documentation has this LOCAL_ROOT_URL but chinese version not.
https://docs.gitea.io/en-us/config-cheat-sheet/#server-server
https://docs.gitea.io/zh-cn/config-cheat-sheet/#server-server

@jinyangcruise commented on GitHub (Jan 9, 2023): > > > Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost > > > > > > I can't find a LOCAL_ROOT_URL in app.ini, should I add it at somewhere? > > Please check the documentation. Thank you very much! Success! By the way, english version documentation has this LOCAL_ROOT_URL but chinese version not. https://docs.gitea.io/en-us/config-cheat-sheet/#server-server https://docs.gitea.io/zh-cn/config-cheat-sheet/#server-server
GiteaMirror commented 2025-11-02 08:57:24 -06:00
Author
Owner
Copy Link

@emehmet commented on GitHub (Jan 10, 2023):

it does not work for me

@emehmet commented on GitHub (Jan 10, 2023): it does not work for me
GiteaMirror commented 2025-11-02 08:57:24 -06:00
Author
Owner
Copy Link

@starpeng commented on GitHub (Jan 10, 2023):

it work for me

Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost

@starpeng commented on GitHub (Jan 10, 2023): it work for me > Workaround: set LOCAL_ROOT_URL with 127.0.0.1, do not use localhost
GiteaMirror commented 2025-11-02 08:57:24 -06:00
Author
Owner
Copy Link

@jinyangcruise commented on GitHub (Jan 10, 2023):

it does not work for me

workaround:

LOCAL_ROOT_URL = http://127.0.0.1:3000/

@jinyangcruise commented on GitHub (Jan 10, 2023): > it does not work for me workaround: LOCAL_ROOT_URL = http://127.0.0.1:3000/
GiteaMirror commented 2025-11-02 08:57:24 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 10, 2023):

it does not work for me

Is your problem the same as others?

@lunny commented on GitHub (Jan 10, 2023): > it does not work for me Is your problem the same as others?
GiteaMirror commented 2025-11-02 08:57:24 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 10, 2023):

So leaving aside the workaround which I am sure will fix the issues people are describing - I don't understand why it is needed or what has changed to make it needed.

As far as I can see the determination of the value of setting.LocalURL (i.e. that which LOCAL_ROOT_URL maps to) has not changed and nor has the dialer for this code.

So I don't understand why this should suddenly be a problem...

@zeripath commented on GitHub (Jan 10, 2023): So leaving aside the workaround which I am sure will fix the issues people are describing - I don't understand why it is needed or what has changed to make it needed. As far as I can see the determination of the value of `setting.LocalURL` (i.e. that which `LOCAL_ROOT_URL` maps to) has not changed and nor has the dialer for this code. So I don't understand why this should suddenly be a problem...
GiteaMirror commented 2025-11-02 08:57:25 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 10, 2023):

For others seeing this conversation the LOCAL_ROOT_URL is in the [server] section of the app.ini and it must be added there.

@zeripath commented on GitHub (Jan 10, 2023): For others seeing this conversation the `LOCAL_ROOT_URL` is in the `[server]` section of the app.ini and it must be added there.
GiteaMirror commented 2025-11-02 08:57:25 -06:00
Author
Owner
Copy Link

@emehmet commented on GitHub (Jan 10, 2023):

Hey @jinyangcruise
It worked as you said.
Thank you! 👍

it does not work for me

workaround:

LOCAL_ROOT_URL = http://127.0.0.1:3000/

@emehmet commented on GitHub (Jan 10, 2023): Hey @jinyangcruise It worked as you said. Thank you! 👍 > > it does not work for me > > workaround: > > LOCAL_ROOT_URL = http://127.0.0.1:3000/
GiteaMirror commented 2025-11-02 08:57:25 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jan 11, 2023):

I think this issue should be re-opened and it needs a patch.

To make the workaround prominent, I didn't say too much about my guess before.

Here is my opinion of this bug:

How it happens?

Gitea (Golang net package) can not resolve host localhost.

Golang's net package need correct /etc/hosts and /etc/nsswitch.conf to resolve domains correctly. If anything is broken, it may not resolve some domains. On Windows, it also depends on C:\Windows\System32\Drivers\etc\hosts file

Why there are so many reports recently?

Possibility 1

Alpine / Go or Go for Windows changed some behaviors which conflict with user's environment, then Golang's net package doens't work well in some rare cases (no evidence yet). But since some users reported that 1.17.x works but 1.18.x fails, maybe there is something changed.

Possibility 2

Many users' systems were already broken, they messed up their hosts file, they might have deleted the 127.0.0.1 localhost line. I know a lot of such users.

Before, some public DNS servers can also resolve localhost, for example, there is still one now:

$ dig localhost @223.5.5.5
;; ANSWER SECTION:
localhost.		2495	IN	A	127.0.0.1

Recently some public DNS servers might have stopped such non-standard behavior, if they do not resolve localhost anymore, the users with broken localhost definition will encounter the problem.

So, some users with broken hosts files can get Gitea working before, but get errors now.

The patch

Approach 1

Use 127.0.0.1 instead of localhost for the default value of LOCAL_ROOT_URL

  • Pros

    • 127.0.0.1 is the de-facto standard loopback IP, it should exist in every OS
    • won't be affected by Host OS/Alpine/Golang anymore (in most cases)
    • even if the user's hosts file is broken, it still works

  • Cons

    • In a pure IPv6 network, the 127.0.0.1 may not exist, but the pure IPv6 network should be pretty rarer than broken hosts files, and a user with pure IPv6 must be an experienced user, they should be able to set LOCAL_ROOT_URL to a IPv6 loopback without any question.

Approach 2

Find the root case why 1.17.x works but 1.18.x doesn't.

Update: maybe it's a Go 1.19 bug: https://github.com/golang/go/issues/53490

And: https://tip.golang.org/doc/go1.19#net

The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however.

Removing the netgo tag from Windows build may resolve the problem.

Approach 3

Try to resolve localhost at startup, report fatal errors if the resolution fails.

@wxiaoguang commented on GitHub (Jan 11, 2023): I think this issue should be re-opened and it needs a patch. To make the workaround prominent, I didn't say too much about my guess before. Here is my opinion of this bug: ### How it happens? Gitea (Golang net package) can not resolve host `localhost`. Golang's net package need correct `/etc/hosts` and `/etc/nsswitch.conf` to resolve domains correctly. If anything is broken, it may not resolve some domains. On Windows, it also depends on `C:\Windows\System32\Drivers\etc\hosts` file ### Why there are so many reports recently? #### Possibility 1 Alpine / Go or Go for Windows changed some behaviors which conflict with user's environment, then Golang's net package doens't work well in some rare cases (no evidence yet). But since some users reported that 1.17.x works but 1.18.x fails, maybe there is something changed. #### Possibility 2 Many users' systems were already broken, they messed up their `hosts` file, they might have deleted the `127.0.0.1 localhost` line. I know a lot of such users. Before, some public DNS servers can also resolve `localhost`, for example, there is still one now: ``` $ dig localhost @223.5.5.5 ;; ANSWER SECTION: localhost. 2495 IN A 127.0.0.1 ``` Recently some public DNS servers might have stopped such non-standard behavior, if they do not resolve localhost anymore, the users with broken localhost definition will encounter the problem. So, some users with broken `hosts` files can get Gitea working before, but get errors now. ### The patch #### Approach 1 Use `127.0.0.1` instead of `localhost` for the default value of LOCAL_ROOT_URL * Pros * 127.0.0.1 is the de-facto standard loopback IP, it should exist in every OS * won't be affected by Host OS/Alpine/Golang anymore (in most cases) * even if the user's `hosts` file is broken, it still works * Cons * In a pure IPv6 network, the 127.0.0.1 may not exist, but the pure IPv6 network should be pretty rarer than broken hosts files, and a user with pure IPv6 must be an experienced user, they should be able to set LOCAL_ROOT_URL to a IPv6 loopback without any question. #### Approach 2 Find the root case why 1.17.x works but 1.18.x doesn't. Update: maybe it's a Go 1.19 bug: https://github.com/golang/go/issues/53490 And: https://tip.golang.org/doc/go1.19#net > The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however. Removing the `netgo` tag from Windows build may resolve the problem. #### Approach 3 Try to resolve `localhost` at startup, report fatal errors if the resolution fails.
GiteaMirror commented 2025-11-02 08:57:25 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 11, 2023):

We could use 127.0.0.1 instead of localhost only on windows then we get none of the cons.

@zeripath commented on GitHub (Jan 11, 2023): We could use 127.0.0.1 instead of localhost only on windows then we get none of the cons.
GiteaMirror commented 2025-11-02 08:57:26 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 11, 2023):

But yes I agree I think this was closed too soon and we need to add a patch - if not for the users, then just to save ourselves time.

@zeripath commented on GitHub (Jan 11, 2023): But yes I agree I think this was closed too soon and we need to add a patch - if not for the users, then just to save ourselves time.
GiteaMirror commented 2025-11-02 08:57:26 -06:00
Author
Owner
Copy Link

@DuaneDu commented on GitHub (Jan 11, 2023):

@zeripath
Config is

[server]
LOCAL_ROOT_URL = http://127.0.0.1:3000/
SSH_DOMAIN       = localhost
DOMAIN           = 192.168.2.50
HTTP_PORT        = 3000
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = D:/work/gitea/data/lfs
LFS_JWT_SECRET   = TGUsxz3aFCZEj8CnOPFzEPUXLhzRTAlOxvd8Rwvl9Q4
OFFLINE_MODE     = false

error
error

console log
consolelog

gitea.log
gitea.log

@DuaneDu commented on GitHub (Jan 11, 2023): @zeripath Config is ``` [server] LOCAL_ROOT_URL = http://127.0.0.1:3000/ SSH_DOMAIN = localhost DOMAIN = 192.168.2.50 HTTP_PORT = 3000 DISABLE_SSH = false SSH_PORT = 22 LFS_START_SERVER = true LFS_CONTENT_PATH = D:/work/gitea/data/lfs LFS_JWT_SECRET = TGUsxz3aFCZEj8CnOPFzEPUXLhzRTAlOxvd8Rwvl9Q4 OFFLINE_MODE = false ``` error ![error](https://user-images.githubusercontent.com/17942048/211757047-d61fc63f-f335-4264-bc49-0e3da22da7c7.png) console log ![consolelog](https://user-images.githubusercontent.com/17942048/211757082-78285bec-79c8-44bc-a74a-9bb1eceee454.png) gitea.log [gitea.log](https://github.com/go-gitea/gitea/files/10390253/gitea.log)
GiteaMirror commented 2025-11-02 08:57:26 -06:00
Author
Owner
Copy Link

@KazzmanK commented on GitHub (Jan 11, 2023):

Same problem for me, windows install, for unknown reason problem raised today, yesterday it was ok.
in hosts we have 127.0.0.1 localhost record. It still calls for dns and fails.
workaround with LOCAL_ROOT_URL helped.

@DuaneDu , add DEV run mode, client will show bit more detailed error message

@KazzmanK commented on GitHub (Jan 11, 2023): Same problem for me, windows install, for unknown reason problem raised today, yesterday it was ok. in hosts we have 127.0.0.1 localhost record. It still calls for dns and fails. workaround with LOCAL_ROOT_URL helped. @DuaneDu , add DEV run mode, client will show bit more detailed error message
GiteaMirror commented 2025-11-02 08:57:26 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 11, 2023):

@DuaneDu your logs now indicate that things are should now be working correctly for you.

Your pre-receive hook is being declined by the user does not have permission to that repo

@zeripath commented on GitHub (Jan 11, 2023): @DuaneDu your logs now indicate that things are should now be working correctly for you. Your pre-receive hook is being declined by the user does not have permission to that repo
GiteaMirror commented 2025-11-02 08:57:27 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jan 11, 2023):

I think it's related to this Go bug:

And: https://tip.golang.org/doc/go1.19#net

The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however.

Removing the netgo tag from Windows build may resolve the problem.

@wxiaoguang commented on GitHub (Jan 11, 2023): I think it's related to this Go bug: * https://github.com/golang/go/issues/53490 And: https://tip.golang.org/doc/go1.19#net > The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however. ---- Removing the `netgo` tag from Windows build may resolve the problem.
GiteaMirror commented 2025-11-02 08:57:27 -06:00
Author
Owner
Copy Link

@natsutteatsuiyone commented on GitHub (Jan 11, 2023):

This webhook error may be related to this issue.

image

2023/01/11 23:20:28 ...s/webhook/webhook.go:122:handle() [E] [63bec58b-9] webhook.Deliver failed: Post "http://dev-738-11/gitea-webhook/post": dial tcp: lookup dev-738-11 on 192.168.10.3:53: server misbehaving

https://gist.github.com/natsutteatsuiyone/4c7b8e3b444a61080bb04ece20b316aa

@natsutteatsuiyone commented on GitHub (Jan 11, 2023): This webhook error may be related to this issue. ![image](https://user-images.githubusercontent.com/6070328/211832651-e6e75e17-2cc8-4a51-b164-f061c1fd9515.png) ``` 2023/01/11 23:20:28 ...s/webhook/webhook.go:122:handle() [E] [63bec58b-9] webhook.Deliver failed: Post "http://dev-738-11/gitea-webhook/post": dial tcp: lookup dev-738-11 on 192.168.10.3:53: server misbehaving ``` https://gist.github.com/natsutteatsuiyone/4c7b8e3b444a61080bb04ece20b316aa
GiteaMirror commented 2025-11-02 08:57:27 -06:00
Author
Owner
Copy Link

@DuaneDu commented on GitHub (Jan 12, 2023):

@zeripath

  1. This account is administrator
  2. this repo is public
  3. this repo is created by me
  4. I have all permission on this repo

image

RUN_MODE=dev
gitea.log
router.log

RUN_MODE=test

gitea.log
router.log

@DuaneDu commented on GitHub (Jan 12, 2023): @zeripath 1. This account is administrator 2. this repo is public 3. this repo is created by me 4. I have all permission on this repo ![image](https://user-images.githubusercontent.com/17942048/211957262-6e2a64d8-a2d7-45fc-8c8e-d14c4c460134.png) RUN_MODE=dev [gitea.log](https://github.com/go-gitea/gitea/files/10397432/gitea.log) [router.log](https://github.com/go-gitea/gitea/files/10397433/router.log) RUN_MODE=test [gitea.log](https://github.com/go-gitea/gitea/files/10397450/gitea.log) [router.log](https://github.com/go-gitea/gitea/files/10397451/router.log)
GiteaMirror commented 2025-11-02 08:57:27 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 16, 2023):

The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however.

It certainly appears that the upstream DNS server it is discovering is doing the incorrect thing for at least localhost...

Removing the netgo tag from Windows build may resolve the problem.

I guess the question is what does the netgo tag do on Windows build and is it really necessary to make a "static" build with it for windows? Removing netgo here:

16e9dec827/Makefile (L759-L764)

would create "Static" builds for windows without the use of netgo.

@zeripath commented on GitHub (Jan 16, 2023): > > The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however. It certainly appears that the upstream DNS server it is discovering is doing the incorrect thing for at least localhost... > Removing the `netgo` tag from Windows build may resolve the problem. I guess the question is what does the netgo tag do on Windows build and is it really necessary to make a "static" build with it for windows? Removing netgo here: https://github.com/go-gitea/gitea/blob/16e9dec8279ae1984db2cb2fb0ea57e0af77f95e/Makefile#L759-L764 would create "Static" builds for windows without the use of netgo.
GiteaMirror commented 2025-11-02 08:57:27 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 16, 2023):

I guess an option is to ask users who are affected if they can run Gitea with the environment variable GODEBUG=netdns=cgo, e.g.:

GODEBUG=netdns=cgo gitea web

That should force the use of the win32 api.

@zeripath commented on GitHub (Jan 16, 2023): I guess an option is to ask users who are affected if they can run Gitea with the environment variable `GODEBUG=netdns=cgo`, e.g.: ```bash GODEBUG=netdns=cgo gitea web ``` That should force the use of the win32 api.
GiteaMirror commented 2025-11-02 08:57:27 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jan 16, 2023):

I have reported the bug to Go team (it has been confirmed as NeedsFix there)

I guess the question is what does the netgo tag do on Windows build and is it really necessary to make a "static" build with it for windows? Removing netgo here:

I guess the netgo in Makefile was just a Copy&Paste and it's not necessary.

And, the netgo seemed to be a no-op on Windows before. But Go 1.19 rewrite the code for it.

So, IMO it's good to remove the netgo tag for Windows build at the moment. When Go team fix the bug, re-enable the netgo tag then (if it's really needed ...)

@wxiaoguang commented on GitHub (Jan 16, 2023): I have reported the bug to Go team (it has been confirmed as NeedsFix there) * https://github.com/golang/go/issues/57757 > I guess the question is what does the netgo tag do on Windows build and is it really necessary to make a "static" build with it for windows? Removing netgo here: I guess the `netgo` in Makefile was just a Copy&Paste and it's not necessary. And, the `netgo` seemed to be a no-op on Windows before. But Go 1.19 rewrite the code for it. So, IMO it's good to remove the `netgo` tag for Windows build at the moment. When Go team fix the bug, re-enable the `netgo` tag then (if it's really needed ...)
GiteaMirror commented 2025-11-02 08:57:28 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 16, 2023):

Agreed I've just looked up the source code for golang and I've come to the same conclusion. netgo only affects lookup on windows and previously was a no-op. Therefore we can and should safely remove until/unless go can make it work correctly.

Are you able to send a PR @wxiaoguang ?

@zeripath commented on GitHub (Jan 16, 2023): Agreed I've just looked up the source code for golang and I've come to the same conclusion. netgo only affects lookup on windows and previously was a no-op. Therefore we can and should safely remove until/unless go can make it work correctly. Are you able to send a PR @wxiaoguang ?
GiteaMirror commented 2025-11-02 08:57:28 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 16, 2023):

As an aside I suspect the problem is here:

d52883f443/src/net/conf.go (L134-L145)

	if c.netGo || r.preferGo() {
		switch c.goos {
		case "windows":
			// TODO(bradfitz): implement files-based
			// lookup on Windows too? I guess /etc/hosts
			// kinda exists on Windows. But for now, only
			// do DNS.
			fallbackOrder = hostLookupDNS
		default:
			fallbackOrder = hostLookupFilesDNS
		}
	}

That code cannot check the /etc/hosts file and thus I bet the dns lookup is going out to an external server and we're getting the external name for the host.

@zeripath commented on GitHub (Jan 16, 2023): As an aside I suspect the problem is here: https://github.com/golang/go/blob/d52883f443e1d564b0300acdd382af1769bf0477/src/net/conf.go#L134-L145 ```go if c.netGo || r.preferGo() { switch c.goos { case "windows": // TODO(bradfitz): implement files-based // lookup on Windows too? I guess /etc/hosts // kinda exists on Windows. But for now, only // do DNS. fallbackOrder = hostLookupDNS default: fallbackOrder = hostLookupFilesDNS } } ``` That code cannot check the /etc/hosts file and thus I bet the dns lookup is going out to an external server and we're getting the external name for the host.
GiteaMirror commented 2025-11-02 08:57:28 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 16, 2023):

DESCRIPTION

This bug is due to a change in Go's handling of the netgo build tag for Windows see:

https://github.com/go-gitea/gitea/issues/22370#issuecomment-1378669025

We were bitten by this because we build our static precompiled binaries with netgo for all platforms. (see https://github.com/go-gitea/gitea/issues/22370#issuecomment-1383936251)

#22467 and #22468 should fix this for 1.18-dev, 1.18.1 and 1.19-dev.

WORKAROUND

For 1.18.0 set the GODEBUG=netdns=cgo environment variable when running gitea.

https://github.com/go-gitea/gitea/issues/22370#issuecomment-1383944400

Builds of what will become 1.18.1 are available now on https://dl.gitea.io/gitea/1.18

@zeripath commented on GitHub (Jan 16, 2023): ## DESCRIPTION This bug is due to a change in Go's handling of the `netgo` build tag for Windows see: https://github.com/go-gitea/gitea/issues/22370#issuecomment-1378669025 We were bitten by this because we build our static precompiled binaries with `netgo` for all platforms. (see https://github.com/go-gitea/gitea/issues/22370#issuecomment-1383936251) #22467 and #22468 should fix this for 1.18-dev, 1.18.1 and 1.19-dev. ## WORKAROUND For 1.18.0 set the `GODEBUG=netdns=cgo` environment variable when running gitea. https://github.com/go-gitea/gitea/issues/22370#issuecomment-1383944400 Builds of what will become 1.18.1 are available now on https://dl.gitea.io/gitea/1.18
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10070
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?