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
This was using 'python_sitelib' in a non-standard way (it got
defined to either python2_sitelib or python3_sitelib depending
on whether we're doing a python2 or python3 build). Igor saw
the uses of 'python_sitelib' and assumed it was just using the
old name for 'the python 2 sitelib' and changed them all to
'python2_sitelib'...which broke all Fedora builds.
This fixes that problem and renames the package's confusing
'python_sitelib' and 'pythonbin' so hopefully no-one will make
the same mistake in future.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
None of currently supported distributions need that.
Last one was EL5 which is EOL for a while.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
This partialy reverts commit 03509b36d5.
It removes just test and keep the functionality.
The test cannot be there right now because tito 0.6.11 and older will choke on this and will produce demaged tarball.
This revert can be added back later when all devel has tito in version 0.6.12 or higher.
Resolves: #337
Add in a check to confirm we get the original root commit has in case there are multiple. This can occur when two separate repositories are merged in to one new one. Without this addition the count will always return 0.
Following the principals of https://nedbatchelder.com/text/unipain.html
our goal is to decode bytes in to unicode as soon as we read them and
encode unicode date to bytes at the last second.
The specific problem we were seeing was caused by calling "encode" on a
byte string rather than a unicode string. Python attempts to be
"helpful" and tries to decode the bytes as ASCII in order to provide a
unicode string to the encode function. Since the bytes aren't ASCII,
the decode fails and we get the UnicodeDecodeError despite the fact that
we never explicitly asked for a decode at all.
Also, calculate checksums correctly for tarballs that have files with
UTF8 characters in the file name.
