automatic import of python-opentimestamps-client

3 files changed, 669 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..b4ebc1f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/opentimestamps-client-0.7.1.tar.gz
diff --git a/python-opentimestamps-client.spec b/python-opentimestamps-client.spec
new file mode 100644
index 0000000..168f5cc
--- /dev/null
+++ b/python-opentimestamps-client.spec
@@ -0,0 +1,667 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-opentimestamps-client
+Version:	0.7.1
+Release:	1
+Summary:	Command-line tool to create and verify OpenTimestamps proofs
+License:	LGPL3
+URL:		https://github.com/opentimestamps/opentimestamps-client
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/8d/37/6402c90b52690b1314d5f8754a8f3e51f9c25047980d326e111f8a6b22b7/opentimestamps-client-0.7.1.tar.gz
+BuildArch:	noarch
+
+Requires:	python3-GitPython
+Requires:	python3-PySocks
+Requires:	python3-appdirs
+Requires:	python3-opentimestamps
+
+%description
+# OpenTimestamps Client
+
+Command-line tool to create and validate timestamp proofs with the
+OpenTimestamps protocol, using the Bitcoin blockchain as a timestamp notary.
+Additionally this package provides timestamping of PGP signed Git commits, and
+verification of timestamps for both Git commits as a whole, and individual
+files within a Git repository.
+
+## Requirements
+
+* Python3
+
+While OpenTimestamps can *create* timestamps without a local Bitcoin node, to
+*verify* timestamps you need a local Bitcoin Core node (a pruned node is fine).
+
+
+## Installation
+
+Either via PyPi:
+
+    $ pip3 install opentimestamps-client
+
+or from source:
+
+    $ python3 setup.py install
+
+On Debian (Stretch) you can install the necessary system dependencies with:
+
+    sudo apt-get install python3 python3-dev python3-pip python3-setuptools python3-wheel
+
+## Usage
+
+Creating a timestamp:
+
+    $ ots stamp README.md
+    Submitting to remote calendar https://a.pool.opentimestamps.org
+    Submitting to remote calendar https://b.pool.opentimestamps.org
+    Submitting to remote calendar https://a.pool.eternitywall.com
+
+You'll see that `README.md.ots` has been created with the aid of three remote
+calendars. We can't verify it immediately however:
+
+    $ ots verify README.md.ots
+    Assuming target filename is 'README.md'
+    Calendar https://alice.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
+    Calendar https://bob.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
+    Calendar https://finney.calendar.eternitywall.com: Pending confirmation in Bitcoin blockchain
+
+It takes a few hours for the timestamp to get confirmed by the Bitcoin
+blockchain; we're not doing one transaction per timestamp.
+
+However, the client does come with a number of example timestamps which you can
+try verifying immediately. Here's a complete timestamp that can be verified
+locally:
+
+    $ ots verify examples/hello-world.txt.ots
+    Assuming target filename is 'examples/hello-world.txt'
+    Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST
+
+You can specify JSON-RPC credentials (`USER` and `PASS`) for a local bitcoin node like so:
+
+    $ ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify examples/hello-world.txt.ots
+    Assuming target filename is 'examples/hello-world.txt'
+    Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST
+
+Incomplete timestamps are ones that require the assistance of a remote calendar
+to verify; the calendar provides the path to the Bitcoin block header:
+
+    $ ots verify examples/incomplete.txt.ots
+    Assuming target filename is 'examples/incomplete.txt'
+    Got 1 new attestation(s) from https://alice.btc.calendar.opentimestamps.org
+    Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST
+
+The client maintains a cache of timestamps it obtains from remote calendars, so
+if you verify the same file again it'll use the cache:
+
+    $ ots verify examples/incomplete.txt.ots
+    Assuming target filename is 'examples/incomplete.txt'
+    Got 1 attestation(s) from cache
+    Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST
+
+You can also upgrade an incomplete timestamp, which adds the path to the
+Bitcoin blockchain to the timestamp itself:
+
+    $ ots upgrade examples/incomplete.txt.ots
+    Got 1 attestation(s) from cache
+    Success! Timestamp is complete
+
+Finally, you can get information on a timestamp, including the actual
+commitment operations and attestations in it:
+
+    $ ots info examples/two-calendars.txt.ots
+    File sha256 hash: efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb
+    Timestamp:
+    append 839037eef449dec6dac322ca97347c45
+    sha256
+     -> append 6b4023b6edd3a0eeeb09e5d718723b9e
+        sha256
+        prepend 57d46515
+        append eadd66b1688d5574
+        verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')
+     -> append a3ad701ef9f10535a84968b5a99d8580
+        sha256
+        prepend 57d46516
+        append 647b90ea1b270a97
+        verify PendingAttestation('https://bob.btc.calendar.opentimestamps.org')
+
+### Timestamping and Verifying PGP Signed Git Commits
+
+See `doc/git-integration.md`
+
+
+## Privacy Security
+
+Timestamping inherently records potentially revealing metadata: the current
+time. If you create multiple timestamps in close succession it's quite likely
+that an adversary will be able to link those timestamps as related simply on
+the basis of when they were created; if you make use of the timestamp multiple
+files in one command functionality (`./ots stamp <file1> <file2> ... <fileN>`)
+most of the commitment operations in the timestamps themselves will be
+identical, providing an adversary very strong evidence that the files were
+timestamped by the same person. Finally, the REST API used to communicate with
+remote calendars doesn't currently attempt to provide any privacy, although it
+could be modified to do so in the future (e.g. with prefix filters).
+
+File contents *are* protected with nonces: a remote calendar learns nothing
+about the contents of anything you timestamp as it only ever receives an opaque
+and meaningless digest. Equally, if multiple files are timestamped at once,
+each file is protected by an individual nonce; the timestamp for one file
+reveals nothing about the contents of another file timestamped at the same
+time.
+
+## Compatibility Expectations
+
+OpenTimestamps is alpha software, so it's possible that timestamp formats may
+have to change in the future in non-backward-compatible ways. However it will
+almost certainly be possible to write conversion tools for any
+non-backwards-compatible changes.
+
+It's very likely that the REST protocol used to communicate with remote
+calendars will change, including in backwards incompatible ways. If this
+happens you'll just need to upgrade your client; existing timestamps will be
+unaffected.
+
+## Calendar Mirroring
+
+As a short-term measure, the raw calendar data for the three calendar servers
+in operation at this time can be downloaded directly. See
+the `contrib/calendar-mirror.sh` script for details.
+
+## Development
+
+Use the setuptools development mode:
+
+    python3 setup.py develop --user
+
+
+## Known Issues
+
+* Need unit tests for the client.
+
+* Git tree re-hashing support fails on certain filenames with invalid unicode
+  encodings; this appears to be due to bugs in the underlying GitPython
+  library. As a work-around, you may find the `convmv` tool useful to find and
+  rename these files.
+
+* Git annex support only works with the SHA256 and SHA256E backends.
+
+* Errors in the Bitcoin RPC communication aren't handled in a user-friendly
+  way.
+
+* Not all Python platforms check SSL certificates correctly. This means that on
+  some platforms, it would be possible for a MITM attacker to intercept HTTPS
+  connections to remote calendars. That said, it shouldn't be possible for such
+  an attacker to do anything worse than give us a timestamp that fails
+  validation, an easily fixed problem.
+
+* ots-git-gpg-wrapper doesn't yet check for you if the timestamp on the git commit
+  makes sense.
+
+* `bitcoin` package can cause issues, with ots confusing it with the
+  required `python-bitcoinlib` package. A symptom of this issue is the
+  message `AttributeError: module 'bitcoin' has no attribute
+  'SelectParams'` or `JSONDecodeError("Expecting value", s, err.value) from None`. To remedy this issue, one must do the following:
+
+```bash
+# uninstall the packages through pip
+pip3 uninstall bitcoin python-bitcoinlib
+
+# remove the bitcoin directory manually from your dist-packages folder
+rm -rf /usr/local/lib/python3.5/dist-packages/bitcoin
+
+# reinstall the required package
+pip3 install python-bitcoinlib
+```
+
+
+
+
+%package -n python3-opentimestamps-client
+Summary:	Command-line tool to create and verify OpenTimestamps proofs
+Provides:	python-opentimestamps-client
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+BuildRequires:	python3-pip
+%description -n python3-opentimestamps-client
+# OpenTimestamps Client
+
+Command-line tool to create and validate timestamp proofs with the
+OpenTimestamps protocol, using the Bitcoin blockchain as a timestamp notary.
+Additionally this package provides timestamping of PGP signed Git commits, and
+verification of timestamps for both Git commits as a whole, and individual
+files within a Git repository.
+
+## Requirements
+
+* Python3
+
+While OpenTimestamps can *create* timestamps without a local Bitcoin node, to
+*verify* timestamps you need a local Bitcoin Core node (a pruned node is fine).
+
+
+## Installation
+
+Either via PyPi:
+
+    $ pip3 install opentimestamps-client
+
+or from source:
+
+    $ python3 setup.py install
+
+On Debian (Stretch) you can install the necessary system dependencies with:
+
+    sudo apt-get install python3 python3-dev python3-pip python3-setuptools python3-wheel
+
+## Usage
+
+Creating a timestamp:
+
+    $ ots stamp README.md
+    Submitting to remote calendar https://a.pool.opentimestamps.org
+    Submitting to remote calendar https://b.pool.opentimestamps.org
+    Submitting to remote calendar https://a.pool.eternitywall.com
+
+You'll see that `README.md.ots` has been created with the aid of three remote
+calendars. We can't verify it immediately however:
+
+    $ ots verify README.md.ots
+    Assuming target filename is 'README.md'
+    Calendar https://alice.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
+    Calendar https://bob.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
+    Calendar https://finney.calendar.eternitywall.com: Pending confirmation in Bitcoin blockchain
+
+It takes a few hours for the timestamp to get confirmed by the Bitcoin
+blockchain; we're not doing one transaction per timestamp.
+
+However, the client does come with a number of example timestamps which you can
+try verifying immediately. Here's a complete timestamp that can be verified
+locally:
+
+    $ ots verify examples/hello-world.txt.ots
+    Assuming target filename is 'examples/hello-world.txt'
+    Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST
+
+You can specify JSON-RPC credentials (`USER` and `PASS`) for a local bitcoin node like so:
+
+    $ ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify examples/hello-world.txt.ots
+    Assuming target filename is 'examples/hello-world.txt'
+    Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST
+
+Incomplete timestamps are ones that require the assistance of a remote calendar
+to verify; the calendar provides the path to the Bitcoin block header:
+
+    $ ots verify examples/incomplete.txt.ots
+    Assuming target filename is 'examples/incomplete.txt'
+    Got 1 new attestation(s) from https://alice.btc.calendar.opentimestamps.org
+    Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST
+
+The client maintains a cache of timestamps it obtains from remote calendars, so
+if you verify the same file again it'll use the cache:
+
+    $ ots verify examples/incomplete.txt.ots
+    Assuming target filename is 'examples/incomplete.txt'
+    Got 1 attestation(s) from cache
+    Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST
+
+You can also upgrade an incomplete timestamp, which adds the path to the
+Bitcoin blockchain to the timestamp itself:
+
+    $ ots upgrade examples/incomplete.txt.ots
+    Got 1 attestation(s) from cache
+    Success! Timestamp is complete
+
+Finally, you can get information on a timestamp, including the actual
+commitment operations and attestations in it:
+
+    $ ots info examples/two-calendars.txt.ots
+    File sha256 hash: efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb
+    Timestamp:
+    append 839037eef449dec6dac322ca97347c45
+    sha256
+     -> append 6b4023b6edd3a0eeeb09e5d718723b9e
+        sha256
+        prepend 57d46515
+        append eadd66b1688d5574
+        verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')
+     -> append a3ad701ef9f10535a84968b5a99d8580
+        sha256
+        prepend 57d46516
+        append 647b90ea1b270a97
+        verify PendingAttestation('https://bob.btc.calendar.opentimestamps.org')
+
+### Timestamping and Verifying PGP Signed Git Commits
+
+See `doc/git-integration.md`
+
+
+## Privacy Security
+
+Timestamping inherently records potentially revealing metadata: the current
+time. If you create multiple timestamps in close succession it's quite likely
+that an adversary will be able to link those timestamps as related simply on
+the basis of when they were created; if you make use of the timestamp multiple
+files in one command functionality (`./ots stamp <file1> <file2> ... <fileN>`)
+most of the commitment operations in the timestamps themselves will be
+identical, providing an adversary very strong evidence that the files were
+timestamped by the same person. Finally, the REST API used to communicate with
+remote calendars doesn't currently attempt to provide any privacy, although it
+could be modified to do so in the future (e.g. with prefix filters).
+
+File contents *are* protected with nonces: a remote calendar learns nothing
+about the contents of anything you timestamp as it only ever receives an opaque
+and meaningless digest. Equally, if multiple files are timestamped at once,
+each file is protected by an individual nonce; the timestamp for one file
+reveals nothing about the contents of another file timestamped at the same
+time.
+
+## Compatibility Expectations
+
+OpenTimestamps is alpha software, so it's possible that timestamp formats may
+have to change in the future in non-backward-compatible ways. However it will
+almost certainly be possible to write conversion tools for any
+non-backwards-compatible changes.
+
+It's very likely that the REST protocol used to communicate with remote
+calendars will change, including in backwards incompatible ways. If this
+happens you'll just need to upgrade your client; existing timestamps will be
+unaffected.
+
+## Calendar Mirroring
+
+As a short-term measure, the raw calendar data for the three calendar servers
+in operation at this time can be downloaded directly. See
+the `contrib/calendar-mirror.sh` script for details.
+
+## Development
+
+Use the setuptools development mode:
+
+    python3 setup.py develop --user
+
+
+## Known Issues
+
+* Need unit tests for the client.
+
+* Git tree re-hashing support fails on certain filenames with invalid unicode
+  encodings; this appears to be due to bugs in the underlying GitPython
+  library. As a work-around, you may find the `convmv` tool useful to find and
+  rename these files.
+
+* Git annex support only works with the SHA256 and SHA256E backends.
+
+* Errors in the Bitcoin RPC communication aren't handled in a user-friendly
+  way.
+
+* Not all Python platforms check SSL certificates correctly. This means that on
+  some platforms, it would be possible for a MITM attacker to intercept HTTPS
+  connections to remote calendars. That said, it shouldn't be possible for such
+  an attacker to do anything worse than give us a timestamp that fails
+  validation, an easily fixed problem.
+
+* ots-git-gpg-wrapper doesn't yet check for you if the timestamp on the git commit
+  makes sense.
+
+* `bitcoin` package can cause issues, with ots confusing it with the
+  required `python-bitcoinlib` package. A symptom of this issue is the
+  message `AttributeError: module 'bitcoin' has no attribute
+  'SelectParams'` or `JSONDecodeError("Expecting value", s, err.value) from None`. To remedy this issue, one must do the following:
+
+```bash
+# uninstall the packages through pip
+pip3 uninstall bitcoin python-bitcoinlib
+
+# remove the bitcoin directory manually from your dist-packages folder
+rm -rf /usr/local/lib/python3.5/dist-packages/bitcoin
+
+# reinstall the required package
+pip3 install python-bitcoinlib
+```
+
+
+
+
+%package help
+Summary:	Development documents and examples for opentimestamps-client
+Provides:	python3-opentimestamps-client-doc
+%description help
+# OpenTimestamps Client
+
+Command-line tool to create and validate timestamp proofs with the
+OpenTimestamps protocol, using the Bitcoin blockchain as a timestamp notary.
+Additionally this package provides timestamping of PGP signed Git commits, and
+verification of timestamps for both Git commits as a whole, and individual
+files within a Git repository.
+
+## Requirements
+
+* Python3
+
+While OpenTimestamps can *create* timestamps without a local Bitcoin node, to
+*verify* timestamps you need a local Bitcoin Core node (a pruned node is fine).
+
+
+## Installation
+
+Either via PyPi:
+
+    $ pip3 install opentimestamps-client
+
+or from source:
+
+    $ python3 setup.py install
+
+On Debian (Stretch) you can install the necessary system dependencies with:
+
+    sudo apt-get install python3 python3-dev python3-pip python3-setuptools python3-wheel
+
+## Usage
+
+Creating a timestamp:
+
+    $ ots stamp README.md
+    Submitting to remote calendar https://a.pool.opentimestamps.org
+    Submitting to remote calendar https://b.pool.opentimestamps.org
+    Submitting to remote calendar https://a.pool.eternitywall.com
+
+You'll see that `README.md.ots` has been created with the aid of three remote
+calendars. We can't verify it immediately however:
+
+    $ ots verify README.md.ots
+    Assuming target filename is 'README.md'
+    Calendar https://alice.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
+    Calendar https://bob.btc.calendar.opentimestamps.org: Pending confirmation in Bitcoin blockchain
+    Calendar https://finney.calendar.eternitywall.com: Pending confirmation in Bitcoin blockchain
+
+It takes a few hours for the timestamp to get confirmed by the Bitcoin
+blockchain; we're not doing one transaction per timestamp.
+
+However, the client does come with a number of example timestamps which you can
+try verifying immediately. Here's a complete timestamp that can be verified
+locally:
+
+    $ ots verify examples/hello-world.txt.ots
+    Assuming target filename is 'examples/hello-world.txt'
+    Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST
+
+You can specify JSON-RPC credentials (`USER` and `PASS`) for a local bitcoin node like so:
+
+    $ ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify examples/hello-world.txt.ots
+    Assuming target filename is 'examples/hello-world.txt'
+    Success! Bitcoin block 358391 attests existence as of 2015-05-28 CEST
+
+Incomplete timestamps are ones that require the assistance of a remote calendar
+to verify; the calendar provides the path to the Bitcoin block header:
+
+    $ ots verify examples/incomplete.txt.ots
+    Assuming target filename is 'examples/incomplete.txt'
+    Got 1 new attestation(s) from https://alice.btc.calendar.opentimestamps.org
+    Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST
+
+The client maintains a cache of timestamps it obtains from remote calendars, so
+if you verify the same file again it'll use the cache:
+
+    $ ots verify examples/incomplete.txt.ots
+    Assuming target filename is 'examples/incomplete.txt'
+    Got 1 attestation(s) from cache
+    Success! Bitcoin block 428648 attests existence as of 2016-09-07 CEST
+
+You can also upgrade an incomplete timestamp, which adds the path to the
+Bitcoin blockchain to the timestamp itself:
+
+    $ ots upgrade examples/incomplete.txt.ots
+    Got 1 attestation(s) from cache
+    Success! Timestamp is complete
+
+Finally, you can get information on a timestamp, including the actual
+commitment operations and attestations in it:
+
+    $ ots info examples/two-calendars.txt.ots
+    File sha256 hash: efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb
+    Timestamp:
+    append 839037eef449dec6dac322ca97347c45
+    sha256
+     -> append 6b4023b6edd3a0eeeb09e5d718723b9e
+        sha256
+        prepend 57d46515
+        append eadd66b1688d5574
+        verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')
+     -> append a3ad701ef9f10535a84968b5a99d8580
+        sha256
+        prepend 57d46516
+        append 647b90ea1b270a97
+        verify PendingAttestation('https://bob.btc.calendar.opentimestamps.org')
+
+### Timestamping and Verifying PGP Signed Git Commits
+
+See `doc/git-integration.md`
+
+
+## Privacy Security
+
+Timestamping inherently records potentially revealing metadata: the current
+time. If you create multiple timestamps in close succession it's quite likely
+that an adversary will be able to link those timestamps as related simply on
+the basis of when they were created; if you make use of the timestamp multiple
+files in one command functionality (`./ots stamp <file1> <file2> ... <fileN>`)
+most of the commitment operations in the timestamps themselves will be
+identical, providing an adversary very strong evidence that the files were
+timestamped by the same person. Finally, the REST API used to communicate with
+remote calendars doesn't currently attempt to provide any privacy, although it
+could be modified to do so in the future (e.g. with prefix filters).
+
+File contents *are* protected with nonces: a remote calendar learns nothing
+about the contents of anything you timestamp as it only ever receives an opaque
+and meaningless digest. Equally, if multiple files are timestamped at once,
+each file is protected by an individual nonce; the timestamp for one file
+reveals nothing about the contents of another file timestamped at the same
+time.
+
+## Compatibility Expectations
+
+OpenTimestamps is alpha software, so it's possible that timestamp formats may
+have to change in the future in non-backward-compatible ways. However it will
+almost certainly be possible to write conversion tools for any
+non-backwards-compatible changes.
+
+It's very likely that the REST protocol used to communicate with remote
+calendars will change, including in backwards incompatible ways. If this
+happens you'll just need to upgrade your client; existing timestamps will be
+unaffected.
+
+## Calendar Mirroring
+
+As a short-term measure, the raw calendar data for the three calendar servers
+in operation at this time can be downloaded directly. See
+the `contrib/calendar-mirror.sh` script for details.
+
+## Development
+
+Use the setuptools development mode:
+
+    python3 setup.py develop --user
+
+
+## Known Issues
+
+* Need unit tests for the client.
+
+* Git tree re-hashing support fails on certain filenames with invalid unicode
+  encodings; this appears to be due to bugs in the underlying GitPython
+  library. As a work-around, you may find the `convmv` tool useful to find and
+  rename these files.
+
+* Git annex support only works with the SHA256 and SHA256E backends.
+
+* Errors in the Bitcoin RPC communication aren't handled in a user-friendly
+  way.
+
+* Not all Python platforms check SSL certificates correctly. This means that on
+  some platforms, it would be possible for a MITM attacker to intercept HTTPS
+  connections to remote calendars. That said, it shouldn't be possible for such
+  an attacker to do anything worse than give us a timestamp that fails
+  validation, an easily fixed problem.
+
+* ots-git-gpg-wrapper doesn't yet check for you if the timestamp on the git commit
+  makes sense.
+
+* `bitcoin` package can cause issues, with ots confusing it with the
+  required `python-bitcoinlib` package. A symptom of this issue is the
+  message `AttributeError: module 'bitcoin' has no attribute
+  'SelectParams'` or `JSONDecodeError("Expecting value", s, err.value) from None`. To remedy this issue, one must do the following:
+
+```bash
+# uninstall the packages through pip
+pip3 uninstall bitcoin python-bitcoinlib
+
+# remove the bitcoin directory manually from your dist-packages folder
+rm -rf /usr/local/lib/python3.5/dist-packages/bitcoin
+
+# reinstall the required package
+pip3 install python-bitcoinlib
+```
+
+
+
+
+%prep
+%autosetup -n opentimestamps-client-0.7.1
+
+%build
+%py3_build
+
+%install
+%py3_install
+install -d -m755 %{buildroot}/%{_pkgdocdir}
+if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
+if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
+if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
+if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
+pushd %{buildroot}
+if [ -d usr/lib ]; then
+	find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/lib64 ]; then
+	find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/bin ]; then
+	find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/sbin ]; then
+	find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+touch doclist.lst
+if [ -d usr/share/man ]; then
+	find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
+fi
+popd
+mv %{buildroot}/filelist.lst .
+mv %{buildroot}/doclist.lst .
+
+%files -n python3-opentimestamps-client -f filelist.lst
+%dir %{python3_sitelib}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 0.7.1-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..4df3131
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+63ddee06b1c1997b085c536b46adfcd5  opentimestamps-client-0.7.1.tar.gz