2023-03-22 10:12:25,643 Files:
2023-03-22 10:12:25,643 fluent-bit_2.0.6-1.dsc
2023-03-22 10:12:25,644 fluent-bit_2.0.6.orig.tar.gz
2023-03-22 10:12:25,777 fluent-bit_2.0.6-1.debian.tar.xz
2023-03-22 10:12:25,778 Files:
2023-03-22 10:12:25,778 librdkafka.dsc
Traceback (most recent call last):
File "/usr/lib/obs/service/obs_gbp", line 30, in <module>
main()
File "/usr/lib/obs/service/obs_gbp", line 26, in main
TarSCM.run()
File "/usr/lib/obs/service/TarSCM/__init__.py", line 39, in run
task_list.process_list()
File "/usr/lib/obs/service/TarSCM/tasks.py", line 131, in process_list
self.process_single_task(task)
File "/usr/lib/obs/service/TarSCM/tasks.py", line 257, in process_single_task
cli = args
File "/usr/lib/obs/service/TarSCM/archive.py", line 370, in create_archive
shutil.copy(input_file, output_file)
File "/usr/lib64/python3.6/shutil.py", line 245, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "/usr/lib64/python3.6/shutil.py", line 120, in copyfile
with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: '/user1/foobar/output/tmpjxhk2m4u/librdkafka.dsc'
2023-03-22 10:12:25,779 Skipping cleanup
As well as finding the generated fluent-bit source package .dsc, as the cloned source repo is also in the same directory it will find any .dsc files there too. (Arguably git repos should not contain .dsc files as they can be generated from control files, but it's not uncommon for some repo to do this for other CI system, and in case of fluent-bit its in a vendored dependency)
I think there might be two options to address this:
Make sure the clones source tree is not in the same directory and the generated source packages (I don't think gpb/dpkg-buildpackage allows control output location, so moving the files from obs_gbp might be needed, or deleting the clone directory before searching for the source packages)
As the source index generated by dpkg-scansources is not actually used, just the list of found .dsc files; perhaps instead of using dpkg-scansource something like find <workdir> -path <scm_object.clone_dir> -prune -o -name '*.dsc' -exec cat '{}' \; which ignores the clone directory.
Spotting while attempting to use obs_gbp to build https://github.com/fluent/fluent-bit/
This looks to be the relevant bit of code:
https://github.com/openSUSE/obs-service-tar_scm/blob/026bf0e08d904f092e7dbdb893bd204efc7f59c9/TarSCM/archive.py#L349
As well as finding the generated fluent-bit source package .dsc, as the cloned source repo is also in the same directory it will find any .dsc files there too. (Arguably git repos should not contain .dsc files as they can be generated from control files, but it's not uncommon for some repo to do this for other CI system, and in case of fluent-bit its in a vendored dependency)
I think there might be two options to address this:
Make sure the clones source tree is not in the same directory and the generated source packages (I don't think gpb/dpkg-buildpackage allows control output location, so moving the files from obs_gbp might be needed, or deleting the clone directory before searching for the source packages)
As the source index generated by dpkg-scansources is not actually used, just the list of found .dsc files; perhaps instead of using dpkg-scansource something like
find <workdir> -path <scm_object.clone_dir> -prune -o -name '*.dsc' -exec cat '{}' \;which ignores the clone directory.