* Extra source file can be copied/moved by some other tool
* When the source file already exists in destination path, then
do not try to copy it once again
* This issue was observed, when we tried to build
subscription-manager on Fedora 32 using tito
Fix#367
We accidentally introduced `copy_extra_sources` method as a part of
`BuilderBase` class. Which wouldn't be a problem, except for the fact
that its implementation uses properties, that are not a part of
that class but are rather defined in **some** of its descendats.
Let's define this method only abstractly and let more specific
builder classes to provide their own implementation if it makes
sense for them.
Fix#364
Previously all non-yes input was considered to be "no". Which is not
what we typically want. There should be expected "yes" inputs, expected
"no" inputs and everything else should be considered to be an uknown
input and should be treated this way.
I think that printing an error for unknown input is too verbose and have
no added value. Simply repeating the question is the way to go here:
##### Please review the above diff #####
Do you wish to proceed with commit? [y/n] foo
Do you wish to proceed with commit? [y/n] y
Proceeding with commit.
It's better to do the python2 and python3 compatibility magic on
one place rather than having having `if PY2` conditions everywhere
and figuring whether to use `builtins.foo` or `__builtin__.foo
over and over again.
Fix#358
Previously the bugzilla-specific code was implemented in `tito.common`
which is imported from everywhere. Therefore missing dependency
to `python3-bugzilla` resulted in failure even for simple commands
such as `tito build --tgz`.
Fix#331
Do not specify `_source_filedigest_algorithm`
and `_binary_filedigest_algorithm` anymore
EPEL5 did understand only MD5 checksums but since it is EOLed and
newer releases know SHA, we can probably safely remove it.
Follow-up for be89941
Fix: #311
Supersedes: #313
The `get_project_name` function is called in an early phase when
the temporary `SOURCES` directory for a current build doesn't exist yet.
Therefore as a little workaround, we set `_sourcedir` to an upstream
directory containing the package spec file.
Defining a custom `_sourcedir` (and therefore not using
`~/rpmbuild/SOURCES`) shouldn't be a problem because tito builds
should not depend on anything outside of the upstream git repository.
The use-case described in PR#313 works as expected.
SOURCE1: somecool.macros
%include %{SOURCE1}
For multi-spec projects, where you have e.g
.
├── foo
│ ├── foo.spec
├── bar
│ ├── bar.spec
It is possible to include the common macros from a parent (or some
other) directory by having a symlink.
cd foo
ln -s ../somecool.macros ./
Or possibly some other way which I am currently not aware of
because I wasn't able to e.g. persuade `%include` to include from
the parent directory.
This method will include extra SOURCE1, SOURCE2, ... SOURCE<N>
files to the source rpm. This fix "No such file or directory" for
included source files.
When running tests for fedora rawhide in Travis, this debug line
fails with following error:
Command output: ls: cannot access
'/tmp/tmpjw15wzfs-titotest/rpmbuild-titotestpkg24v2hy67/SOURCES/titotestpkg-0.0.1/':
Operation not permitted
Even when changing the debug line to just
debug('', 'ls -l /')
it still fails. Let's just use `os.listdir`
Support the popular pip editable installation mode.
To work-around a problem in setuptools' develop target, generalize
'install_dir' to say all packages are in 'src' (for more info, see:
https://github.com/pypa/pip/issues/126).
Remove pre-generated bin/tito-dev script.
Create tito.cli.main() which serves as command line's entry point that
can be used:
- by setuptools' 'console_scripts' entry point mechanism for automatic
script creation,
- via 'if __name__ == "__main__":'.
Remove pre-generated bin/tito script.
Update SPEC file.
