Learn more about these different git repos.
Other Git URLs
Seems like shallow submodules are not supported:
$ git clone https://github.com/cgsecurity/testdisk --depth 1 --shallow-submodules $ cd testdisk/ $ rpkg srpm --spec testdisk-copr.spec fatal: ambiguous argument '': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' git_dir_pack: archiving /testdisk: fatal: not a valid object name: ERROR: git_dir_pack: Error during source creation. git_dir_pack name=testdisk failed with value 128.
While with full --recursive submodule clone it works:
$ git clone https://github.com/cgsecurity/testdisk --depth 1 --recursive $ cd testdisk rpkg srpm --spec testdisk-copr.spec git_dir_pack: archiving /testdisk: commit 2c2b9e20e7bebe510aede9200db62e21079e3ac8 (grafted, HEAD -> master, origin/master, origin/HEAD) Author: Christophe Grenier <grenier@cgsecurity.org> Date: Fri Apr 8 16:17:43 2022 +0200 Fix the build with rpkg-util v3+ git_dir_pack: Wrote: /tmp/rpkg/testdisk-copr-5-zcsic8c9/testdisk-2c2b9e20.tar.gz Wrote: /tmp/rpkg/testdisk-copr-5-zcsic8c9/testdisk-copr.spec setting SOURCE_DATE_EPOCH=1453593600 Wrote: /tmp/rpkg/testdisk-copr-5-zcsic8c9/testdisk-0.0.git.1.2c2b9e20-0.fc35.src.rpm
Ye, it seems it works with git_dir_archive but not with git_dir_pack.
git_dir_archive
git_dir_pack
So the work-around is to use git_dir_archive?
Hello,
I have debugged the problem for a bit. It actually doesn't even work with git_dir_archive. The problem is this function https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/helpers/git_submodule_refs#_13 which fails and exits on the /usr/bin/git ls-tree ... when the submodule isn't cloned (in this particular case it is becbcc35956102e064fc603720182113d887a180 /root/testdisk/doc submodule which causes the error). Probably because it just can't traverse git metadata of the submodule as it is not present.
/usr/bin/git ls-tree ...
becbcc35956102e064fc603720182113d887a180 /root/testdisk/doc
I am not sure what is the expected behavior here. I think the submodule needs to be cloned for us to be able to archive it - unless we would clone it additionally on demand which I imagine could be maybe a separate flag to allow that. Is that correct? I think the error could be more user-friendly in either case.
Hello, I have debugged the problem for a bit. It actually doesn't even work with git_dir_archive. The problem is this function https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/helpers/git_submodule_refs#_13 which fails and exists on the /usr/bin/git ls-tree ... when the submodule isn't cloned (in this particular case it is becbcc35956102e064fc603720182113d887a180 /root/testdisk/doc submodule which causes the error). Probably because it just can't traverse git metadata of the submodule as it is not present. I am not sure what is the expected behavior here. I think the submodule needs to be cloned for us to be able to archive it - unless we would clone it additionally on demand which I imagine could be maybe a separate flag to allow that. Is that correct? I think the error could be more user-friendly in either case.
I have debugged the problem for a bit. It actually doesn't even work with git_dir_archive. The problem is this function https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/helpers/git_submodule_refs#_13 which fails and exists on the /usr/bin/git ls-tree ... when the submodule isn't cloned (in this particular case it is becbcc35956102e064fc603720182113d887a180 /root/testdisk/doc submodule which causes the error). Probably because it just can't traverse git metadata of the submodule as it is not present.
Actually, I have just realized we don't actually archive recursively at the moment so this should work and the git_submodule_refs shouldn't probably exit by an error but could return only partial submodule tree (in this case just root probably). I would however add an extra flag to this helper for this behavior because maybe at some point the original behavior (throwing an error) might be more desirable (e.g. in case of recursive archive).
Login to comment on this ticket.