Re: [PATCH cygport] xorg.cygclass: Allow configuration of default SRC_URI compression
On Mon, 2022-04-11 at 13:58 +0100, Jon Turney wrote: > Historically, xorg packages were usually provided as .gz and .bz2 > compressed tarballs. The current trend is to no longer provide .bz2, > but .gz and .xz instead. Allow the compression to be configured, with a > backwards compatible default. If all or even most current packages use .xz, then maybe just default to that and define XORG_SRC_COMPRESSION for the (current) exceptions? -- Yaakov
Re: [ITA] duplicity
> 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
Fwd: update urls for cygwinports
--- Begin Message --- I'm working to phase out the ftp urls on my main website, and see these files in cygwinports using the ftp urls: byacc/byacc.cygport dialog/dialog.cygport diffstat/diffstat.cygport luit/luit.cygport ncurses/ncurses.cygport tack/tack.cygport xterm/xterm.cygport The change is ftp://ftp.invisible-island.net/XXX to https://invisible-island.net/archives/XXX At the moment I have files in both places, and am working to have package scripts updated before pulling the plug on ftp. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature --- End Message ---
Re: replacing a previous package verson
> On 11/04/2022 14:02, Andrew Schulman via Cygwin-apps wrote:
> > After all this time I feel that I should know the answer to this, but here
> > goes.
> >
> > I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1,
> > leaving fish-3.3.1-1 as the previous release.
> >
> > What's the best way to do this? Should I create override.hint, with
>
> > keep: 3.3.1-1
>
> This alone means 'keep 3.3.1-1 as well as anything else you would keep'.
>
> Since that seems to be what you really want ('keep previous major
> version around '), I'd suggest just doing that.
Thanks!
Re: replacing a previous package verson
On 11/04/2022 14:45, Andrew Schulman via Cygwin-apps wrote: After all this time I feel that I should know the answer to this, but here goes. I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1, leaving fish-3.3.1-1 as the previous release. What's the best way to do this? Should I create override.hint, with keep: 3.3.1-1 replace-versions: 3.4.0-1 ? This seems as though it might be right, but one question I have is, will override.hint persist in future releases unless I replace it? Or, should I just set prev: 3.3.1-1 in fish.cygport, and let cygport and calm handle it from there? The explicit 'prev/test/curr: ' lines which could appear in setup.hint aren't supported anymore (see [1]), since there are now different, hopefully better and less ambiguous ways of conveying that information. [1] https://cygwin.com/pipermail/cygwin-apps/2020-March/039948.html
Re: replacing a previous package verson
On 11/04/2022 14:02, Andrew Schulman via Cygwin-apps wrote:
After all this time I feel that I should know the answer to this, but here
goes.
I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1,
leaving fish-3.3.1-1 as the previous release.
What's the best way to do this? Should I create override.hint, with
keep: 3.3.1-1
This alone means 'keep 3.3.1-1 as well as anything else you would keep'.
Since that seems to be what you really want ('keep previous major
version around '), I'd suggest just doing that.
If you really feel the presence of 3.4.0-1 is unhelpful and want to
remove it, you can use the 'deleting' instructions at [1] to remove 3.4.0-1.
You can create the dash-prefixed files in cygport's staging directory
(${PN}-${PVR}.${ARCH}/dist/) before a 'cygport upload', if you want to
make both changes at once.
Since that mechanism is not terribly easy to use, it's also ok to ask
here for someone with shell access to remove the files for you. (The
script which does this is named 'vault', so this is sometimes referred
to as 'vaulting').
But I'd suggest just focusing on specifying what you want to keep, and
allow calm to manage cleaning up stuff that's surplus to requirements
for you.
[1] https://cygwin.com/package-upload.html#deleting
replace-versions: 3.4.0-1
This isn't what you want.
'replace-versions' is an instruction to setup, that those versions
should always be replaced, even by non-superseding (lower) versions.
This is to intended to handle the case when a broken package is
released, and we want to withdraw that package without releasing a later
version, and downgrade it anywhere it's installed.
That's the idea the final paragraph after [2] is meant to communicate.
[2] https://cygwin.com/packaging-hint-files.html#override.hint
? This seems as though it might be right, but one question I have is, will
override.hint persist in future releases unless I replace it?
Yes, override.hint persists until changed or removed (but note that it's
contents don't currently apply recursively).
Re: replacing a previous package verson
> After all this time I feel that I should know the answer to this, but here > goes. > > I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1, > leaving fish-3.3.1-1 as the previous release. > > What's the best way to do this? Should I create override.hint, with > > keep: 3.3.1-1 > replace-versions: 3.4.0-1 > > ? This seems as though it might be right, but one question I have is, will > override.hint persist in future releases unless I replace it? Or, should I just set prev: 3.3.1-1 in fish.cygport, and let cygport and calm handle it from there?
replacing a previous package verson
After all this time I feel that I should know the answer to this, but here goes. I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1, leaving fish-3.3.1-1 as the previous release. What's the best way to do this? Should I create override.hint, with keep: 3.3.1-1 replace-versions: 3.4.0-1 ? This seems as though it might be right, but one question I have is, will override.hint persist in future releases unless I replace it? Thanks, Andrew
[PATCH cygport] xorg.cygclass: Allow configuration of default SRC_URI compression
Historically, xorg packages were usually provided as .gz and .bz2
compressed tarballs. The current trend is to no longer provide .bz2,
but .gz and .xz instead. Allow the compression to be configured, with a
backwards compatible default.
---
cygclass/xorg.cygclass | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/cygclass/xorg.cygclass b/cygclass/xorg.cygclass
index 2049fd5..519ea8f 100644
--- a/cygclass/xorg.cygclass
+++ b/cygclass/xorg.cygclass
@@ -143,11 +143,22 @@ SUMMARY="X.Org ${ORIG_PN} component"
# DEFINITION
HOMEPAGE="https://www.x.org/;
#
+
+#o* xorg.cygclass/XORG_SRC_COMPRESSION
+# DESCRIPTION
+# The compression extension used in the default SRC_URI, set by the xorg
+# cygclass. For backwards compatibility, this defaults to 'bz2', but a
+# different value may be needed for X.Org packages which no longer provide
+# tarballs using that compression.
+# DEFINITION
+XORG_SRC_COMPRESSION="${XORG_SRC_COMPRESSION:-bz2}"
+#
+
#o* xorg.cygclass/SRC_URI (xorg)
# DESCRIPTION
# Download location of the release tarball.
#
-SRC_URI="https://www.x.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
+SRC_URI="https://www.x.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.${XORG_SRC_COMPRESSION};
#o* xorg.cygclass/GIT_URI (xorg)
# DESCRIPTION
--
2.35.1
