好几次遇到阿里云的镜像更新有问题了,明明某个库有了最新版,但阿里云就是报版本不存在。今天又出现了这样的情况,安装laravel-zero的时候,require-dev中有个laravel/pint ^1.2,直接就报了
3、清除:composer config -g --unset repos.packagist
膘叔的简单人生
好几次遇到阿里云的镜像更新有问题了,明明某个库有了最新版,但阿里云就是报版本不存在。今天又出现了这样的情况,安装laravel-zero的时候,require-dev中有个laravel/pint ^1.2,直接就报了
在很久很久以前,我其实一直是使用阿里云的,直到后面腾讯也出了云。当然使用量明显没有阿里大,而且我还一直是推荐阿里的。
突然发现uniapp好象无法分类。
其实我一直在想,这个功能什么时候会被关掉。
远程操作家里的mac mini进行更新的时候,突然报错:
mini:Homebrew mini$ brew update
Warning: No available formula with the name "ca-certificates".
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching for a previously deleted formula (in the last month)...
Warning: homebrew/core is shallow clone. To get its complete history, run:
git -C "$(brew --repo homebrew/core)" fetch --unshallow
Error: No previously deleted formula found.
==> Searching taps on GitHub...
Error: No formulae found in taps.
Error:
homebrew-core is a shallow clone.
To `brew update`, first run:
git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
This command may take a few minutes to run due to the large size of the repository.
This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core and Homebrew/homebrew-cask. We don't do this for you
automatically to avoid repeatedly performing an expensive unshallow operation in
CI systems (which should instead be fixed to not use shallow clones). Sorry for
the inconvenience!
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out
fatal: the remote end hung up unexpectedly
GIT_TRACE=2 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
10:29:28.798061 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/bin/git
10:29:28.798668 exec-cmd.c:236 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/bin
10:29:28.799328 git.c:418 trace: built-in: git fetch --unshallow
10:29:28.801482 run-command.c:643 trace: run_command: GIT_DIR=.git git-remote-https origin https://mirrors.ustc.edu.cn/homebrew-core.git
10:29:28.812513 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git-remote-https
10:29:28.813122 exec-cmd.c:236 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
10:29:28.929816 run-command.c:643 trace: run_command: git fetch-pack --stateless-rpc --stdin --lock-pack --include-tag --thin --depth=2147483647 https://mirrors.ustc.edu.cn/homebrew-core.git/
10:29:28.935164 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git
10:29:28.935863 exec-cmd.c:236 trace: resolved executable dir: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
10:29:28.936585 git.c:418 trace: built-in: git fetch-pack --stateless-rpc --stdin --lock-pack --include-tag --thin --depth=2147483647 https://mirrors.ustc.edu.cn/homebrew-core.git/
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out
fatal: the remote end hung up unexpectedly
在我的页面中第一行,其实以前一直有一行:<!--<!DOCTYPE html><head></head><body></body></html>-->
节后了,悄悄的用cloudflare做了个cdn前置,感觉速度确实快了不少。
在Vite创建的项目中,如果直接使用process.env变量会报错,说是process未定义。查了下资料,原来这是vite3移除了这个变量:https://github.com/vitejs/vite/issues/1973
在项目的vite.config.ts的export default defineConfig中,增加节点:define{'process.env':{}}
如果要和你的env变量一致可以先loadEnv:
const root = process.cwd();
const env = loadEnv(mode,root);
关于这podman啊,一天天的,都在说要替换docker,然后也是大家各种说怎么弄怎么弄,教你安装podman之后,alias docker="podman" ,然后pip3 install podman-compose,再alias一条 alias docker-compose="podman-compose",说的这样好象就差不多了
The proxy is set correctly: proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused
The problem is that your proxy is listening on 127.0.0.1. Obviously 127.0.0.1 inside the VM is a different address and therefore it cannot connect to the proxy on you actual host.
If you set http_proxy=socks5://host.containers.internal:7890 before you run podman machine init it should work.
Maybe podman should just s/127.0.0.1/host.containers.internal and s/localhost/host.containers.internal automatically when it copies the proxy value from the host.
I just test it and I think you are right, but I don't know why http_proxy=socks5://host.containers.internal:7890 podman machine init this command still hit the same error but it works as expected when I add 127.0.0.1 host.containers.internal to my host file
however it works now
add item blow to host file
127.0.0.1 host.containers.internal
and change proxy to
http_proxy=socks5://host.containers.internal:7890
then everything works fine
much thanks @Luap99 for your help and I close this issues for the problem is solved, but I still stay concerned if some day podman can do this itself and no need to change proxy setting
```
呵呵,这么麻烦?我还是新建一个shell窗口:podman machine stop && podman machine init && podman machine start吧。
然后,podman pull mysql,一切正常~
至此搞定。
> 假装内容支持markdown,因为新模板在寻找中,现在的html所见所得,估计会全部改成markdown,先尝试一下。
一直使用github,也有因为各种原因使用过不少的git server,比如:codeup/gitee/coding/甚至腾讯工蜂,国外的么,bitbucket/gitlab其实也都有使用,这里面带来的最大的问题就是网络问题,当然国内的没这个毛病,但比如gitee,不能超过3个协作者(个人账户),coding的话,我个人是很喜欢的,甚至想成为他们的商业用户,但商业用户需要至少5个使用者。(国内好象其他平台也差不多,要想成为商业用户,几乎最少人数都是5人,一年500多我愿意付出,但2500多确实没有太大必要)