> Run cygport ... all with --debug flag which enables shell tracing
I'll answer it myself. If the cygport is given the filename *without*
".cygport" extension, it executes, but wrongly detects the PVR -
NAME/VERSION/RELEASE. When I provided full name, it works as I'd
expected. I think this deserves improvement.
Probably caused by TAB completion when it stopped on the first "."
because python-fasteners.cygport file exists and also the
python-fasteners.noarch existed already from previous run in the same
directory.
Regards,
Libor
I'll try to forget how many hours it took.
Dne 10.04.2022 v 20:26 Libor Ukropec napsal(a):
Hi Brian,
1. regarding python-fasteners:
Dne 08.04.2022 v 1:44 Brian Inglis napsal(a):
> Run cygport ... all with --debug flag which enables shell tracing
> throughout and redirect all output &> debug.log for review.
Output for command `cygport --debug python-fasteners download all check
&> debug.log`
is here, if you can deduct from it something useful:
https://gist.github.com/cz6ace/929812203a42bd2d69506cad19385eed#file-debug-log
(it is quite long, I do not want to paste it directly into the email)
Also it is unknown to me, how the new repository can be added into the
https://cygwin.com/git/?a=project_list;pf=git/cygwin-packages so I can
execute the tests in the playground too.
2. regarding duplicity itself. My first successful build:
https://github.com/cygwin/scallywag/actions/runs/2144688591
Regards,
Libor
Dne 08.04.2022 v 1:44 Brian Inglis napsal(a):
Run cygport ... all with --debug flag which enables shell tracing
throughout and redirect all output &> debug.log for review.
On 2022-04-07 16:26, Libor Ukropec wrote:
Hi Brian,
I solved the issue with Python 2.7 by adding PKG_NAMES and *_CONTENTS:
inherit python-wheel
PYTHON_WHEEL_VERSIONS="2.7:3.8:3.9"
NAME="python-fasteners"
VERSION=0.16.3
RELEASE=1
CATEGORY="Python"
SUMMARY="Cross platform locks for threads and processes."
DESCRIPTION="Python standard library provides a lock for threads
(both a reentrant one, and a non-reentrant one, see below). Fasteners
extends this, and provides a lock for processes, as well as Reader
Writer locks for both threads and processes."
SRC_URI="https://github.com/harlowja/fasteners/archive/refs/tags/${VERSION}.tar.gz";
SRC_DIR="fasteners-${VERSION}"
ARCH=noarch
PKG_NAMES+=" python27-fasteners"
python27_fasteners_CONTENTS="usr/lib/python2.7/site-packages/
usr/share/doc/python27-fasteners/"
still I'm concerned about the generated requirements, where the
package itself is referring to itself with very long name. Is that
normal?
>>> python38-fasteners requires: python38
python38-fasteners-python-fasteners-fasteners python38-six
>>> python39-fasteners requires: python39
python39-fasteners-python-fasteners-fasteners python39-six
>>> python27-fasteners requires: python27
python27-fasteners-python-fasteners-fasteners python27-six
Libor
Dne 07.04.2022 v 21:39 Libor Ukropec napsal(a):
Hi Brian,
Dne 07.04.2022 v 1:40 Brian Inglis napsal(a):
On 2022-04-06 16:10, Libor Ukropec wrote:
I'd like to offer to adopt maintenance of duplicity (Encrypted
bandwidth-efficient backup system)
Information from https://duplicity.gitlab.io/ - """The last stable
0.7 release is *0.7.19*, released Apr 19, 2019""", while cygwin
contains 0.7.11 from 2017
Updated cygport:
https://github.com/cz6ace/cygwin-duplicity
You need to define BUILD_REQUIRES and list all Cygwin packages
needed to build this package:
https://cygwin.github.io/cygport/check_funcs_cygpart.html#robo791
Use BUILD_REQUIRES+=" ..." for additional lines of packages.
Updated build:
https://github.com/cz6ace/cygwin-duplicity/releases
See:
https://cygwin.com/git/cygwin-packages/duplicity.git
This repository was my starting point, I just increased the version
and prepared the package (below) for the new python dependency
(fasterners). I did not see on the contribution page any mention to
the `playground` thing and an automation - will try that, once my
SSH key is added.
As my first contribution to cygwin I wanted to start with small
steps and stay with 0.7 duplicity, which still depends on the Python
2.7
You can clone the repo for the original files, checkout a
playground branch, commit your changes and patches (and any extra
source files), define the upstream playground branch, and push your
changes there, which will run Scallywag CI under Github Actions (or
Appveyor if you configure that cygport option).
Please note for successful installation the python 2.7 fasteners
package is required, not yet in cygwin, I plan to offer [ITP] for it:
cygport:
https://github.com/cz6ace/cygwin-python-fasteners
build:
https://github.com/cz6ace/cygwin-python-fasteners/releases
Need to support python3/39 now: see python package cygports in
cygwin-packages repos as above!
Is it a must at this moment? As I stated above, duplicity 0.7.x
requires Python 2.7
I changed the `inherit` to python-wheel, which should support
2.7,3.8, 3.9:
inherit python-wheel
PYTHON_WHEEL_VERSIONS="2.7:3.8:3.9"
But the cygport does not create the tar.cz archive for 2.7 and fails
with
... <shortened the list>
-usr/lib/python2.7/site-packages/fasteners/version.py
...
*** ERROR: Packages are missing files:
I tried previous cygport version, but it fails creating python 3.7
package.
I'll try to look to cygport sources if I am able to see something,
which I doubt.
Python standard library provides a lock for threads (both a
reentrant one, and a non-reentrant one, see below). Fasteners
extends this, and provides a lock for processes, as well as Reader
Writer locks for both threads and processes.
This library (in newer version) is also present in LInux
distributions, e.g. Ubuntu:
https://packages.ubuntu.com/source/focal/s390x/python-fasteners
