Closed ReillyBrogan closed 1 year ago
CC @GZGavinZhao
I think this is caused by a faulty .gitmodules
file, which tries to fetch a submodule outside of the project root instead of an actual "remote":
[submodule "tests/auto/qml/ecmascripttests/test262"]
path = tests/auto/qml/ecmascripttests/test262
url = ../qtdeclarative-testsuites.git
branch = snapshot-20180312-3c69133-based
I think it may be better to just use HTTP source, as that is the single git submodule qtdeclarative
has. Is there a reason you're using Git source?
Hmm I see what's going on. The remote's relative url would point to https://invent.kde.org/qt/qt/qtdeclarative-testsuites.git
, but we're doing two cloning. The second cloning (which is when submodules are fetched) clones from the staging path into the final path, which cause the testsuite's url to evaluate to a local path. Maybe an option should be added to clone into final path directly.
I think it may be better to just use HTTP source, as that is the single git submodule qtdeclarative has. Is there a reason you're using Git source?
The KDE folk have specifically asked that the functionality for generating a tarball from a git commit not be used for qt5 as it causes a greater amount of load on their systems compared to doing a git clone. There's otherwise no http source for qt5 as it's only maintained as a git branch and doesn't see releases (you pretty much just use whatever the latest commit on the kde/5.15
branch is at the time of building). Note that if you look into that repo you'll see tags but those are deceiving as those are the upstream tags while the repo is maintained as a series of backports on top of the upstream QT tag.
TLDR this unfortunately does need to work with git cloning otherwise I'm going to need to host my own converted git -> http source which is icky.
Maybe an option should be added to clone into final path directly.
If I understand you right this might be the best option.
Maybe an option should be added to clone into final path directly.
If I understand you right this might be the best option.
I think so too. I'll do that then.
Also the hanging issue will be gone when the libgit2 back-end is used. That code is all finished and tested, I just need to clean it up.
How do I actually use this? I've tried defining my source as the following and it's not working (guessing based off of the code changes, but this should really be documented):
upstreams :
- git|https://invent.kde.org/qt/qt/qtdeclarative.git:
ref: 05c3f4921d81fb1b0eb497515c24ae56221d1e0a
# Relative submodules
staging: false
Not in front of the computer, but I recall that in my testing I used staging: no
. Your inference is correct, I think it's just some yaml weirdness.
I'm trying to package qt5-declarative which has the following upsteam:
git|https://invent.kde.org/qt/qt/qtdeclarative.git : 05c3f4921d81fb1b0eb497515c24ae56221d1e0a
This fails with the following error message (and also hangs requiring ctrl+c):
However I can use git to do this manually and it works: