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.
nothing says that the version number must start with a number as seen in
the gpg-pubkey packages in Fedora:
gpg-pubkey-facb00b1-570a8081
gpg-pubkey-c3898297-5d25cdbd
gpg-pubkey-d38b4796-570c8cd3
gpg-pubkey-cfc659b9-5b6eac67
before this, packages with a name like "foo-1-setup" would be end up
parsed as "foo" and confused the heck out of the whitelisting code.
the new regex is less greedy about numbers by expecting the tag to end
in something that looks like a version (any number of numbers, dots and
hyphens) followed by an optional "dash anything" for the release.
[root@8d279f4efad9 /]# rpm -q --specfile tito.spec
error: Recursion depth(17) greater than max(16)
This problem seems to appear only on EL6, but either way
the macro definition makes no sense (at least to me).
Fixing this build error
line 40: cd: tito-tito-0.6.12: No such file or directory
We don't need the weird directory naming because it is possible to
pass an optional part of the URL specifying the targeted filename.
See https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Tags
However, we still can't define `Source0` as an URL because then the
checksum differs from what `tito build --tgz` produces
