xrepo 命令一直无响应 about xmake HOT 21 CLOSED

这边可以，应该是访问 github 的问题。。

$ xrepo info miniz
updating repositories .. ok
The package info of project:
    require(miniz): 
      -> description: miniz: Single C source file zlib-replacement library
      -> version: 2.2.0
      -> license: MIT
      -> urls:
         -> https://github.com/richgel999/miniz/archive/refs/tags/2.2.0.tar.gz
            -> bd1136d0a1554520dcb527a239655777148d90fd2d51cf02c36540afc552e6ec
         -> https://github.com/richgel999/miniz.git
            -> 2.2.0
      -> repo: xmake-repo https://gitee.com/tboox/xmake-repo.git master
      -> cachedir: /Users/ruki/.xmake/cache/packages/2406/m/miniz/2.2.0
      -> installdir: /Users/ruki/.xmake/packages/m/miniz/2.2.0/def2ee03ffd34d2aa9fc242b65b210c7
      -> searchdirs: 
      -> searchnames:
         -> miniz-2.2.0.tar.gz
         -> 2.2.0.tar.gz
         -> miniz (git)
      -> fetchinfo: 2.2.0, remote(in xmake-repo)
      -> platforms: all
      -> requires:
         -> plat: macosx
         -> arch: x86_64
         -> configs:
            -> pic: true
            -> shared: false
            -> debug: false
      -> configs:
         -> shared: Build shared library. (default: false) (readonly)
      -> configs (builtin):
         -> debug: Enable debug symbols. (default: false)
         -> pic: Enable the position independent code. (default: true)
         -> lto: Enable the link-time build optimization. (type: boolean)
         -> asan: Enable the address sanitizer. (type: boolean)
         -> runtimes: Set the compiler runtimes.
            -> values: {"MT","MTd","MD","MDd","c++_static","c++_shared","stdc++_static","stdc++_shared"}
         -> vs_runtime: Set vs compiler runtime.
            -> values: {"MT","MTd","MD","MDd"}
         -> toolchains: Set package toolchains only for cross-compilation.
         -> cflags: Set the C compiler flags.
         -> cxflags: Set the C/C++ compiler flags.
         -> cxxflags: Set the C++ compiler flags.
         -> asflags: Set the assembler flags.
         -> ldflags: Set the binary linker flags.
         -> shflags: Set the shared library linker flags.

from xmake.

这边可以，应该是访问 github 的问题。。

$ xrepo info miniz
updating repositories .. ok
The package info of project:
    require(miniz): 
      -> description: miniz: Single C source file zlib-replacement library
      -> version: 2.2.0
      -> license: MIT
      -> urls:
         -> https://github.com/richgel999/miniz/archive/refs/tags/2.2.0.tar.gz
            -> bd1136d0a1554520dcb527a239655777148d90fd2d51cf02c36540afc552e6ec
         -> https://github.com/richgel999/miniz.git
            -> 2.2.0
      -> repo: xmake-repo https://gitee.com/tboox/xmake-repo.git master
      -> cachedir: /Users/ruki/.xmake/cache/packages/2406/m/miniz/2.2.0
      -> installdir: /Users/ruki/.xmake/packages/m/miniz/2.2.0/def2ee03ffd34d2aa9fc242b65b210c7
      -> searchdirs: 
      -> searchnames:
         -> miniz-2.2.0.tar.gz
         -> 2.2.0.tar.gz
         -> miniz (git)
      -> fetchinfo: 2.2.0, remote(in xmake-repo)
      -> platforms: all
      -> requires:
         -> plat: macosx
         -> arch: x86_64
         -> configs:
            -> pic: true
            -> shared: false
            -> debug: false
      -> configs:
         -> shared: Build shared library. (default: false) (readonly)
      -> configs (builtin):
         -> debug: Enable debug symbols. (default: false)
         -> pic: Enable the position independent code. (default: true)
         -> lto: Enable the link-time build optimization. (type: boolean)
         -> asan: Enable the address sanitizer. (type: boolean)
         -> runtimes: Set the compiler runtimes.
            -> values: {"MT","MTd","MD","MDd","c++_static","c++_shared","stdc++_static","stdc++_shared"}
         -> vs_runtime: Set vs compiler runtime.
            -> values: {"MT","MTd","MD","MDd"}
         -> toolchains: Set package toolchains only for cross-compilation.
         -> cflags: Set the C compiler flags.
         -> cxflags: Set the C/C++ compiler flags.
         -> cxxflags: Set the C++ compiler flags.
         -> asflags: Set the assembler flags.
         -> ldflags: Set the binary linker flags.
         -> shflags: Set the shared library linker flags.

访问GitHub是没问题的

ping github.com
PING github.com (20.205.243.166): 56 data bytes
64 bytes from 20.205.243.166: icmp_seq=0 ttl=110 time=62 ms
64 bytes from 20.205.243.166: icmp_seq=1 ttl=110 time=62 ms
64 bytes from 20.205.243.166: icmp_seq=2 ttl=110 time=62 ms
64 bytes from 20.205.243.166: icmp_seq=3 ttl=110 time=61 ms
^C
--- github.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 75.944/76.399/76.813/0.308 ms

from xmake.

可以参考这个 看下栈。。
#2033

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Title: xrepo command has been unresponsive

Xmake version

v2.9.3+20240624

Operating system version and architecture

macOS 14.4.1

Describe the problem

Using xmake installed with brew, there is no response when using the xrepo command:

xrepo info miniz
xmake require --search miniz

I checked the warehouse: https://xrepo.xmake.io/#/packages/macosx?id=miniz-macosx, and it turns out that the miniz library exists. I don’t know if it’s a network problem or my own problem.

Expected results

xrepo runs normally and can download dependency packages

Project configuration

add_rules("mode.debug", "mode.release")

target("xmake-demo")
    set_kind("binary")
    add_files("src/*.cpp")

Additional information and error logs

No output

xrepo install miniz -vD
xmake require --search miniz -vD

from xmake.

可以参考这个 看下栈。。 #2033

输出如下：

xmake require --search zlib
<subprocess: sysctl>: /usr/sbin/sysctl -n machdep.cpu.vendor machdep.cpu.model machdep.cpu.family machdep.cpu.features machdep.cpu.brand_string
<subprocess: which>: which ping
<subprocess: ping>: /Applications/Yunshu.app/Contents/Public/ping -c 1 -t 1 127.0.0.1
^C[xmake]: [engine]: 1000
stack traceback:
	[C]: in function 'base/io.poller_wait'
	@programdir/core/base/poller.lua:115: in function 'base/poller.wait'
	@programdir/core/base/scheduler.lua:1063: in function 'base/scheduler.runloop'
	@programdir/core/main.lua:333: in function 'main.entry'
	(...tail calls...)
[1]    7243 segmentation fault  xmake require --search zlib

from xmake.

看下 /Applications/Yunshu.app/Contents/Public/ping -c 1 -t 1 127.0.0.1 会不会卡

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Check if /Applications/Yunshu.app/Contents/Public/ping -c 1 -t 1 127.0.0.1 is stuck.

from xmake.

看下 /Applications/Yunshu.app/Contents/Public/ping -c 1 -t 1 127.0.0.1 会不会卡

所以是这个软件影响了？奇怪的是，这个软件并没有运行

/Applications/Yunshu.app/Contents/Public/ping -c 1 -t 1 127.0.0.1
failed to lookup address information: nodename nor servname provided, or not known
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=1 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.053/0.053/0.053/0.000 ms
^C%                                                                                                                       

from xmake.

看进程发现/Applications/Yunshu.app/Contents/Public/ping进程在后台，kill之后再执行xmake require --search zlib成功显示结果。
但是执行xrepo install miniz -vD时，还是会卡住。似乎，xrepo会调用ping命令，而调用到非系统的ping？

xrepo install miniz -vD
<subprocess: sysctl>: /usr/sbin/sysctl -n machdep.cpu.vendor machdep.cpu.model machdep.cpu.family machdep.cpu.features machdep.cpu.brand_string
<subprocess: xmake>: /opt/homebrew/bin/xmake f -c --require=n
<subprocess: xmake>: /opt/homebrew/bin/xmake require -j 10 --extra={system=false} miniz -vD
<subprocess: sysctl>: /usr/sbin/sysctl -n machdep.cpu.vendor machdep.cpu.model machdep.cpu.family machdep.cpu.features machdep.cpu.brand_string
<subprocess: which>: which unzip
<subprocess: unzip>: /usr/bin/unzip -v
<subprocess: which>: which git
<subprocess: git>: /opt/homebrew/bin/git --version
<subprocess: which>: which gzip
<subprocess: gzip>: /usr/bin/gzip --version
<subprocess: which>: which tar
<subprocess: tar>: /usr/bin/tar --version
<subprocess: which>: which ping
<subprocess: ping>: /Applications/Yunshu.app/Contents/Public/ping -c 1 -t 1 127.0.0.1
^C[xmake]: [engine]: 1000
stack traceback:
	[C]: in function 'base/io.poller_wait'
	@programdir/core/base/poller.lua:115: in function 'base/poller.wait'
	@programdir/core/base/scheduler.lua:1063: in function 'base/scheduler.runloop'
	@programdir/core/main.lua:333: in function 'main.entry'
	(...tail calls...)
[xmake]: [engine]: 1000
stack traceback:
	[C]: in function 'base/io.poller_wait'
	@programdir/core/base/poller.lua:115: in function 'base/poller.wait'
	@programdir/core/base/scheduler.lua:1063: in function 'base/scheduler.runloop'
	@programdir/core/main.lua:333: in function 'main.entry'
	(...tail calls...)
/opt/homebrew/bin/xrepo: line 7: 11036 Segmentation fault: 11  $BASEDIR/xmake lua private.xrepo "$@"

from xmake.

会去从 which ping 返回的结果找 ping 。。它返回了这个，就用了这个。。。反正是这个 ping 有问题。。

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Will look for ping in the results returned from which ping. . It returned this and used this. . . It's this ping that's problematic anyway. .

from xmake.

会去从 which ping 返回的结果找 ping 。。它返回了这个，就用了这个。。。反正是这个 ping 有问题。。

用whereis会不会更好一些

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Will look for ping in the results returned from which ping. . It returned this and used this. . . It's this ping that's problematic anyway. .

Would it be better to use whereis?

from xmake.

会去从 which ping 返回的结果找 ping 。。它返回了这个，就用了这个。。。反正是这个 ping 有问题。。

用whereis会不会更好一些

跟用哪个没关系，即使 whereis 更好，也不会弃用 which ，只会增加一种查找方式 去辅助改进结果。。
但是不管用哪种，都不能保证它返回的 ping 路径一定是对的，一定没问题，即使你这通过 whereis 绕过了，说不定其他用户也还会遇到类似的。

这种用户自身环境问题，只有你这自己处理下。。

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Will look for ping in the results returned from which ping. . It returned this and used this. . . It's this ping that's problematic anyway. .

Would it be better to use whereis

It doesn't matter which one is used. Even if whereis is better, which will not be abandoned. It will only add a search method to help improve the results. .
But no matter which one is used, there is no guarantee that the ping path it returns will be correct and there will be no problem. Even if you bypass it through whereis, other users may encounter similar problems.

This kind of user environment problem can only be solved by yourself. .

from xmake.

会去从 which ping 返回的结果找 ping 。。它返回了这个，就用了这个。。。反正是这个 ping 有问题。。

用whereis会不会更好一些

跟用哪个没关系，即使 whereis 更好，也不会弃用 which ，只会增加一种查找方式 去辅助改进结果。。 但是不管用哪种，都不能保证它返回的 ping 路径一定是对的，一定没问题，即使你这通过 whereis 绕过了，说不定其他用户也还会遇到类似的。

这种用户自身环境问题，只有你这自己处理下。。

是否可以加一个超时，不然会无意义的无限等待

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Will look for ping in the results returned from which ping. . It returned this and used this. . . It's this ping that's problematic anyway. .

Would it be better to use whereis?

It doesn’t matter which one is used. Even if whereis is better, which will not be abandoned. It will only add a search method to help improve the results. . But no matter which one is used, there is no guarantee that the ping path it returns will be correct and there will be no problem. Even if you bypass it through whereis, other users may encounter similar problems.

This kind of user environment problem can only be solved by yourself. .

Is it possible to add a timeout, otherwise it will be meaningless and infinite waiting?

from xmake.

会去从 which ping 返回的结果找 ping 。。它返回了这个，就用了这个。。。反正是这个 ping 有问题。。

用whereis会不会更好一些

跟用哪个没关系，即使 whereis 更好，也不会弃用 which ，只会增加一种查找方式 去辅助改进结果。。 但是不管用哪种，都不能保证它返回的 ping 路径一定是对的，一定没问题，即使你这通过 whereis 绕过了，说不定其他用户也还会遇到类似的。
这种用户自身环境问题，只有你这自己处理下。。

是否可以加一个超时，不然会无意义的无限等待

参数本身 -t 1 就是设置了超时 最多等 1s ，但是这个特殊的 ping 老卡着，我也没办法。。如果是正常的 ping 老早返回了。

ping -c 1 -t 1 127.0.0.1

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

Will look for ping in the results returned from which ping. . It returned this and used this. . . It's this ping that's problematic anyway. .

Would it be better to use whereis?

It doesn't matter which one is used. Even if whereis is better, which will not be abandoned. It will only add a search method to help improve the results. . But no matter which one is used, there is no guarantee that the ping path it returns will be correct and there will be no problem. Even if you bypass it through whereis, other users may encounter similar problems.
This kind of user environment problem can only be solved by yourself. .

Is it possible to add a timeout, otherwise it will be meaningless and infinite waiting?

The parameter itself -t 1 sets the timeout and waits up to 1s, but this particular ping keeps getting stuck, and there is nothing I can do about it. .

ping -c 1 -t 1 127.0.0.1

from xmake.

这种你自己处理下，让 which 找对 ping 就行了。。用户环境问题

from xmake.

Bot detected the issue body's language is not English, translate it automatically.

You can handle this yourself and let which find the right ping. . User environment issues

from xmake.