rpm-software-management/tito

Patch files are not copied into the temporary source directory

FrostyX opened this issue · 5 comments

It seems that tito doesn't properly copy patches into the temporary source directory

git clone https://gitlab.com/yorickpeterse/fedora-lua-language-server.git
cd fedora-lua-language-server

[jkadlcik@zeratul fedora-lua-language-server]$ tito build --srpm --test 
Creating output directory: /tmp/tito
Building package [lua-language-server-3.6.11-1]
Wrote: /tmp/tito/lua-language-server-git-1.6f36fbd.tar.gz
...
Command output: ['', 'setting SOURCE_DATE_EPOCH=1677542400', 'error: Bad file: /tmp/tito/rpmbuild-lua-language-serverz0az3zeh/SOURCES/missing-cstdint-header.patch: No such file or directory', '', 'RPM build errors:', '    Bad file: /tmp/tito/rpmbuild-lua-language-serverz0az3zeh/SOURCES/missing-cstdint-header.patch: No such file or directory']

Traceback (most recent call last):
  File "/usr/bin/tito", line 33, in <module>
    sys.exit(load_entry_point('tito==0.6.22', 'console_scripts', 'tito')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/tito/cli.py", line 910, in main
    CLI().main(sys.argv[1:])
  File "/usr/lib/python3.11/site-packages/tito/cli.py", line 209, in main
    return module.main(argv)
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/tito/cli.py", line 392, in main
    return builder.run(self.options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/tito/builder/main.py", line 162, in run
    self.srpm()
  File "/usr/lib/python3.11/site-packages/tito/builder/main.py", line 246, in srpm
    output = run_command_func(cmd)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/tito/common.py", line 353, in run_command_print
    raise RunCommandException(command, status, "\n".join(output))
tito.exception.RunCommandException: Error running command: rpmbuild  --eval '%undefine scl' --define "_topdir /tmp/tito/rpmbuild-lua-language-serverz0az3zeh" --define "_sourcedir /tmp/tito/rpmbuild-lua-language-serverz0az3zeh/SOURCES" --define "_builddir /tmp/tito/rpmbuild-lua-language-serverz0az3zeh/BUILD" --define "_srcrpmdir /tmp/tito" --define "_rpmdir /tmp/tito"   --nodeps -bs /tmp/tito/rpmbuild-lua-language-serverz0az3zeh/SOURCES/lua-language-server-git-1.6f36fbd/lua-language-server.spec

But the patch file is both in the git repo

[jkadlcik@zeratul fedora-lua-language-server]$ ls
3.6.11.tar.gz  lua-language-server.spec  missing-cstdint-header.patch  wrapper

and in the spec file

[jkadlcik@zeratul fedora-lua-language-server]$ cat lua-language-server.spec |grep Patch
Patch0: missing-cstdint-header.patch

so it should have been copied into the temporary source directory.

Per #447, the workaround is to explicitly list the patch as a Source, so:

...
Source0: ...
Source1: kittens.patch
Patch0:  kittens.patch
...

The idea, when Tito was born, was not use patches at all. Or rather work on git with patches applied.

Try this:

#have the git without patches
tito tag
git branch downstream
git checkout downstream
# apply patches, git commit it
# in tito.props change:
#   tagger to  tito.tagger.ReleaseTagger
#   builder to DistributionBuilder
tito tag
tito build --srpm

and you should end up with srpm where every commit after the branching is separate PatchX in spec file.

@xsuchy That likely won't work in my case, as I need to patch files in sub modules included in the project that's being built. If tito doesn't want to support patch files that's fine, but then I think it should at least produce a warning of sorts when encountering PachX: lines 😃

abn commented

Just chiming in a use case where it makes a lot of sense for tito to be aware of patch files.

In my case, I am packaging an upstream project that does not have official RPMs. The project snapshot with the scenario is available at https://github.com/abn/web-eid-rpm/tree/77375a6.

  • The upstream source is included as a submodule at a tag.
  • The file that has to be patched is a submodule nested two levels deeper.
  • In-tree patch commits are not really an option.

I was able to workaround this by using in upstream commit patch url. See abn/web-eid-rpm@6f5f585.

Source0: %{name}-%{version}.tar.gz
Patch0:  https://github.com/web-eid/libpcsc-mock/commit/488cb42301a42d8ced964a0aaafe4be0d258126d.patch

The flip side here obviously is that build environment require access to internet. Not necessarily an issue as this is being built on copr.

IMHO, it might be a great time to revisit the strictness around the use of patches as it seems tito might have seen adoption outside its original intended use cases.

I also have tried using tito in this way where we will be carrying downstream patches to build on Fedora. The basic layout works:

pytorch.spec
0001-some.patch
0002-someother.patch

But as soon as we try to manage multiple spec files with patches, the patches go missing in the same way described here.

pytorch/pytorch.spec
pytorch/0001-some.patch
pytorch/0002-someother.patch
cpuinfo/cpuinfo.spec
cpuinfo/0001-somethingweneed.patch