You are not logged in.
This might be more of a package problem but I want to start getting to the bottom of these on the forums because the issue with two packages are similar. I have cemu and wine-ge-custom already installed and these issues started two day ago. When I tried to install cemu with manual (empty dir and installing of AUR package same problems exist so it's not the yay problem.
The main thing I see is: fatal: transport 'file' not allowed but haven't find any issues what that entails.
If I try to install cemu package from AUR I get this kind of error:
==> Starting prepare()...
Cloning into '/home/christooss/aur/cemu/src/Cemu/dependencies/cubeb'...
fatal: transport 'file' not allowed
fatal: clone of 'file:///home/christooss/aur/cemu/src/cubeb' into submodule path '/home/christooss/aur/cemu/src/Cemu/dependencies/cubeb' failed
Failed to clone 'dependencies/cubeb'. Retry scheduled
Cloning into '/home/christooss/aur/cemu/src/Cemu/dependencies/cubeb'...
fatal: transport 'file' not allowed
fatal: clone of 'file:///home/christooss/aur/cemu/src/cubeb' into submodule path '/home/christooss/aur/cemu/src/Cemu/dependencies/cubeb' failed
Failed to clone 'dependencies/cubeb' a second time, aborting
==> ERROR: A failure occurred in prepare().
Aborting...
and similar one when updating/installing with wine-ge-custom:
==> Starting prepare()...
~/.cache/yay/wine-ge-custom/src/wine-ge-custom ~/.cache/yay/wine-ge-custom/src
Submodule 'proton-wine' (http://github.com/gloriouseggroll/proton-wine/) registered for path 'proton-wine'
Synchronizing submodule url for 'proton-wine'
Cloning into '/home/christooss/.cache/yay/wine-ge-custom/src/wine-ge-custom/proton-wine'...
fatal: transport 'file' not allowed
fatal: clone of '/home/christooss/.cache/yay/wine-ge-custom/src/proton-wine-ge' into submodule path '/home/christooss/.cache/yay/wine-ge-custom/src/wine-ge-custom/proton-wine' failed
Failed to clone 'proton-wine'. Retry scheduled
Cloning into '/home/christooss/.cache/yay/wine-ge-custom/src/wine-ge-custom/proton-wine'...
fatal: transport 'file' not allowed
fatal: clone of '/home/christooss/.cache/yay/wine-ge-custom/src/proton-wine-ge' into submodule path '/home/christooss/.cache/yay/wine-ge-custom/src/wine-ge-custom/proton-wine' failed
Failed to clone 'proton-wine' a second time, aborting
==> ERROR: A failure occurred in prepare().
Aborting...
Thanks for the answers.
Last edited by christooss (2022-10-19 20:44:25)
Offline
I had this problem as well. This is due to the git 2.38.0-1 -> 2.38.1-1 update.
[ANNOUNCE] Git v2.38.1 and others - Junio C Hamano mentions:
Additionally, the value of `protocol.file.allow` is changed to be "user" by default.
So one method is to change that back:
$ git config --global protocol.file.allow always
I wonder if there's a less aggressive approach, specifically for Pacman or AUR Pacman wrappers.
Last edited by simonzack (2022-10-19 14:46:22)
Offline
Why would you use --global? That could be set --local just for the repo in question, and ideally it would be set upstream in the repo config.
EDIT: to clarify, using --global would be any easy way to not face this issue anymore. But it only does so by excluding yourself from the set of people impacted by a packaging bug. It should really be fixed in the package as the PKGBUILD should not rely on assumptions about the end user's system configuration: if it requires a specific configuration is should specify it.
Last edited by Trilby (2022-10-19 15:10:09)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It looks like this change will break every PKGBUILD using this: https://wiki.archlinux.org/title/VCS_pa … submodules
Offline
Does replacing
git submodule update
with
git submodule--helper update
help?
Offline
@loqs: Yes,
git submodule--helper update
works. Time to update a whole bunch of PKGBUILDs--including appimagelauncher.
Last edited by yochananmarqos (2022-10-19 19:52:13)
Offline
This helped. Thanks @Ioqs.
Offline
What does this command do that git submodule update doesn't?
Offline
What does this command do that git submodule update doesn't?
git submodule uses /usr/lib/git-core/git-submodule which is the shell script https://github.com/git/git/blob/v2.38.1 … bmodule.sh which sets GIT_PROTOCOL_FROM_USER=0 [1] internally it uses git submodule--helper [2].
[1] https://github.com/git/git/blob/v2.38.1 … ule.sh#L29
[2] https://github.com/git/git/blob/v2.38.1 … le.sh#L338
Offline
So it's like using an internal script to bypass a security measure?
I tried this inside a PKGBUILD, but the error stay the same:
git config protocol.file.allow always
(...)
git submodule update
Offline
For some reason the setting seems to only be respected when it is set in the global config. No idea if this is a bug or intended.
Offline
bit premature to just be switching all PKGBUILDS to use submodule--helper. seems more like an ugly workaround hack than a real fix to the issue.
the actual fix would need to be to pacman, as makepkg, part of pacman, is the thing that is doing this local cloning magic behind the scenes that no longer works. it was relying on git behavior that no longer exists.
edit: I've created a bug for this https://bugs.archlinux.org/task/76255 - note that as the bug report shows, this doesn't just affect aur packages. there are plenty of packages in the official arch repos with PKGBUILDs that rely on this submodule mechanism during builds. @yochananmarqos I think it is really unwise to start using internal git functionality that isn't even meant to be used, particularly if it is for the purpose of circumventing security measures. you have no guarantees as to the behavior of this internal non-exposed function. this whole problem started because the behavior of an actual-meant-to-be-used function changed, the solution is not to introduce even-more-likely-to-fail-in-the-future stuff imo
Last edited by justinkb (2022-10-20 11:59:49)
Offline
You just have to replace
git submodule update ...
by
git -c protocol.file.allow=always submodule update ...
Offline
I know this a year old post, but for anyone who is still stuck, my last method is to do
git config --global protocol.file.allow always
and then
git config --system protocol.file.allow always
Also, I put the global parameter in there too since I cant do an exact replica of the situation at the moment. Arch is not letting me see how I solved it, as I too got this error.
Offline
Setting that option gobally/systemwide is not needed as benjarobin mentioned #13 .
For those needing more info : https://wiki.archlinux.org/title/VCS_pa … submodules
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Closing this old solved thread.
Offline