Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch files are not copied into the temporary source directory #446

Open
FrostyX opened this issue Feb 28, 2023 · 5 comments
Open

Patch files are not copied into the temporary source directory #446

FrostyX opened this issue Feb 28, 2023 · 5 comments
Labels
bug Something is clearly a bug effort/medium Can be done in 1-2 days gain/medium Affects multiple users

Comments

@FrostyX
Copy link
Member

FrostyX commented Feb 28, 2023

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.

@FrostyX FrostyX added the bug Something is clearly a bug label Feb 28, 2023
@yorickpeterse
Copy link

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

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

@xsuchy
Copy link
Member

xsuchy commented Mar 1, 2023

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.

@yorickpeterse
Copy link

yorickpeterse commented Mar 1, 2023

@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 😃

neverpanic added a commit to neverpanic/copr-crypto-auditing-openssl that referenced this issue May 9, 2023
Tito does not copy patches into its temporary %_specdir, which causes
the build with tito to fail. Since we're just using tito as a glorified
way to download an upstream tarball before the build, this isn't the
behavior we want.

Fortunately, we can work around it by mentioning all patch files as
sources, and a bit of regex magic makes this simple to do.

See rpm-software-management/tito#446.

Signed-off-by: Clemens Lang <cllang@redhat.com>
@abn
Copy link
Contributor

abn commented Jun 23, 2023

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.

@damaestro
Copy link

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

@FrostyX FrostyX added effort/medium Can be done in 1-2 days gain/medium Affects multiple users labels Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is clearly a bug effort/medium Can be done in 1-2 days gain/medium Affects multiple users
Projects
None yet
Development

No branches or pull requests

5 participants