[PATCH 0/7] cygcheck-dep updates
Brian Inglis (7):
support better compressed setup.xz instead of bz2
fix no version for -C if only test release available
make cygcheck-dep executable
add /etc/{postinstall,preremove}/cygcheck-dep.sh
rename cygcheck-dep.sh to etc-preremove-cygcheck-dep.sh
add postinstall script to create cache dir
minimize cache dir preremove script
cygcheck-dep| 27 +++
etc-postinstall-cygcheck-dep.sh | 1 +
etc-preremove-cygcheck-dep.sh | 1 +
3 files changed, 17 insertions(+), 12 deletions(-)
mode change 100644 => 100755 cygcheck-dep
create mode 100755 etc-postinstall-cygcheck-dep.sh
create mode 100755 etc-preremove-cygcheck-dep.sh
--
2.39.0
From e59d6fb3b4008536ee57865d64372a42a9c93277 Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To:
References:
From: Brian Inglis
Date: Fri, 27 Oct 2023 13:25:20 -0600
Subject: [PATCH 1/7] support better compressed setup.xz instead of bz2
Signed-off-by: Brian Inglis
---
cygcheck-dep | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/cygcheck-dep b/cygcheck-dep
index 15c6be5a7193..72e345f80987 100644
--- a/cygcheck-dep
+++ b/cygcheck-dep
@@ -610,24 +610,24 @@ mach="${MACHTYPE%%-*}"
## download file /*
cw_setup_ini="$cache_dir/cygwin/$mach/setup.ini"
if ! [ "$opt_use_cached_setup_ini" ] || [ "$cmd_show_updates" ]; then
- cw_setup_bz2_url="ftp://sourceware.org/pub/cygwin/$mach/setup.bz2;
+ cw_setup_url="https://cygwin.com/pub/cygwin/$mach/setup.xz;
[ "$opt_be_more_verbose" ] && opt_wget_verbosity="-nv" ||
opt_wget_verbosity="-q"
- if ! wget >&2 "$opt_wget_verbosity" -r -nH --cut-dirs 1 -P "$cache_dir"
"$cw_setup_bz2_url"; then
+ if ! wget >&2 "$opt_wget_verbosity" -r -nH --cut-dirs 1 -P "$cache_dir"
"$cw_setup_url"; then
echo >&2 "$0: failed to download file:"
-echo >&2 "$0: $cw_setup_bz2_url"
+echo >&2 "$0: $cw_setup_url"
echo >&2 "$0: you may try to run with -c option to use cached file from
previous download"
exit 4
fi
- cw_setup_bz2="$cache_dir/cygwin/$mach/setup.bz2"
- if ! bzip2 -t "$cw_setup_bz2"; then
+ cw_setup="$cache_dir/cygwin/$mach/setup.xz"
+ if ! unxz -t "$cw_setup"; then
echo >&2 "$0: failed to check integrity of downloaded file:"
-echo >&2 "$0: $cw_setup_bz2"
+echo >&2 "$0: $cw_setup"
echo >&2 "$0: you may try to run with -c option to use cached file from
previous download"
exit 5
fi
- if ! bzcat "$cw_setup_bz2" > "$cw_setup_ini"; then
+ if ! xzcat "$cw_setup" > "$cw_setup_ini"; then
echo >&2 "$0: failed to decompress downloaded file:"
-echo >&2 "$0: $cw_setup_bz2"
+echo >&2 "$0: $cw_setup"
exit 6
fi
fi
--
2.39.0
From a349a1ddfc1c199bad04e59d7eb6c7fe7d4d2ff2 Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To:
References:
From: Brian Inglis
Date: Fri, 27 Oct 2023 13:26:50 -0600
Subject: [PATCH 2/7] fix no version for -C if only test release available
Signed-off-by: Brian Inglis
---
cygcheck-dep | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/cygcheck-dep b/cygcheck-dep
index 72e345f80987..5b7fa4cda9d9 100644
--- a/cygcheck-dep
+++ b/cygcheck-dep
@@ -11,7 +11,7 @@
### DECLARATIONS
name="cygcheck-dep"
-version="3.0"
+version="3.0-4"
## version(), help() /*
@@ -645,17 +645,20 @@ fi
L=''; P=''; C=''; R=''; V=''; O=''; D=''; T=''
## read and parse file; populate ${PkgID[]}, ${PkgName[]}, et al.
/*
+# fix no version for -C if only test release available:
+# hold buffer => version seen: new package clears; version sets;
+# test label checks and cycles if no version, otherwise skips rest of package
L="$(sed -n '
:begin
-/^@\s\+\(\S\+\)\s*$/{s//add_new_package_to_catalogue "\1"/p; b}
+/^@\s\+\(\S\+\)\s*$/{s//add_new_package_to_catalogue "\1"/p; s/.*//; h; b}
/^category:\s\+\(_obsolete\)\s*$/{s//PkgCategories[$MaxPkgID]="\1";
T="obsolete package"/p; b}
/^category:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//__make_list C "\1";
PkgCategories[$MaxPkgID]="$C"; T=''/p; b}
-/^version:\s\+\(\S\+\)\s*$/{s//PkgVersionAvailable[$MaxPkgID]="\1"/p; b}
+/^version:\s\+\(\S\+\)\s*$/{s//PkgVersionAvailable[$MaxPkgID]="\1"/p; h; b}
/^obsoletes:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//__make_list O "\1" ",";
PkgObsoletedPkgs[$MaxPkgID]="$O"/p; b}
/^requires:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//[ "$T" ] \&\& { __make_list R
"\1"; PkgRequisitesDeclared[$MaxPkgID]="$R"; }/p; b}
/^depends2:\s\+\(\S\+\(\s\+\S\+\)*\)\s*$/{s//__make_list R "\1" ","; [
"$T" ] \&\& ObsoletePkgs[$MaxPkgID]="$R" ||
PkgRequisitesDeclared[$MaxPkgID]="$R"/p; b}
/^\[prev\]/{:skip-prev n; /^@/b begin; b skip-prev}
-/^\[test\]/{:skip-test n; /^@/b begin; b skip-test}
+/^\[test\]/{:skip-test g; /^.\+$/!b; n; /^@/b begin; b skip-test}
' "$cw_setup_ini")"
eval "$L"
L=''
--
2.39.0
From adf3ca292284f1daf735baf2eb1c7fc8108ef2cc Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To:
References:
From: Brian Inglis
Date:
Re: [ITA] libvpx
On 2023-10-27 09:19, Jon Turney via Cygwin-apps wrote:
On 26/10/2023 16:56, Brian Inglis via Cygwin-apps wrote:
Hi folks,
I have built an updated release of libvpx with the CVE fixes included.
This is a Google WebM project which does not use autotools or libtool, so the
last maintainer did their own cygvpx dll build and relinked the executables.
Taking a brief look over the cygport, if you're going to abstract out the
soversion, you can use 'declare' to evaluate variable names
e.g.
ABI=8
PKG_NAMES="... libvpx${ABI} ..."
declare libvpx${ABI}_SUMMARY="$SUMMARY (runtime)"
declare libvpx${ABI}_CONTENTS="usr/bin/cygvpx-${ABI}.dll"
Thanks Jon,
I never realized that, so will now be using it in a number of packages where ABI
changes occur.
The current test programs do not relink against the unstripped dll, possibly
because of their sizes requiring > 32 bit offsets, so I am no longer relinking
the test programs with the dll, only the distributed utilities.
$ du libvpx-1.13.1-1.x86_64/{build,inst/usr/bin}/*.{dll,exe}
23M libvpx-1.13.1-1.x86_64/build/cygvpx-8.dll
26M libvpx-1.13.1-1.x86_64/build/test_intra_pred_speed.exe
158M libvpx-1.13.1-1.x86_64/build/test_libvpx.exe
33M libvpx-1.13.1-1.x86_64/build/test_rc_interface.exe
3.3M libvpx-1.13.1-1.x86_64/build/vpxdec.exe
3.5M libvpx-1.13.1-1.x86_64/build/vpxenc.exe
3.4M libvpx-1.13.1-1.x86_64/inst/usr/bin/cygvpx-8.dll
680K libvpx-1.13.1-1.x86_64/inst/usr/bin/vpxdec.exe
700K libvpx-1.13.1-1.x86_64/inst/usr/bin/vpxenc.exe
With codec performance tests disabled, this build also downloads 1.4GB of test
data files from Google under:
https://storage.googleapis.com/downloads.webmproject.org/test_data/libvpx/
which we presumably would prefer not to include in the src package, to
Yeah, including it seems a bad idea.
run tests which take 2.75-3.5 hours out of a 3.75-4.5 hour build, with 5
failures in scallywag CI and 2 failures locally out of 1596 tests, shown in
the attached log, so I have questions into the upstream WebM libvpx project
about those.
Full scallywag logs are available at:
https://cygwin.com/cgi-bin2/jobs.cgi?id=7148=libvpx=Brian+Inglis
Thanks.
I've added this to your packages.
Cheers!
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: [cygport PATCH] Check for pythonXX-wheel when using python-wheel
On 27/10/2023 09:41, Adam Dinwoodie via Cygwin-apps wrote:
The python wheel package is required for building using the python-wheel
cygclass, but nothing in cygport verifies its existence, and the error
from the Python commands themselves aren't particularly helpful either.
To avoid other people wasting the time I just did trying to debug Python
build errors, check if the relevant wheel executable is installed, and
complain if it isn't.
Thanks. Applied.
Depending on the path taken to hit the error, this seems like it might
well be an oversight in 2596f685, for which I apologise.
---
cygclass/python-wheel.cygclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/cygclass/python-wheel.cygclass b/cygclass/python-wheel.cygclass
index 4f71639d..3f274b98 100644
--- a/cygclass/python-wheel.cygclass
+++ b/cygclass/python-wheel.cygclass
@@ -111,6 +111,7 @@ do
esac
check_prog_req pip${ver} python${ver//.}-pip
+ check_prog_req wheel-${ver} python${ver//.}-wheel
done
#o* python-wheel.cygclass/PKG_NAMES (python-wheel)
Re: [ITA] libvpx
On 26/10/2023 16:56, Brian Inglis via Cygwin-apps wrote:
Hi folks,
I have built an updated release of libvpx with the CVE fixes included.
This is a Google WebM project which does not use autotools or libtool,
so the last maintainer did their own cygvpx dll build and relinked the
executables.
Taking a brief look over the cygport, if you're going to abstract out
the soversion, you can use 'declare' to evaluate variable names
e.g.
ABI=8
PKG_NAMES="... libvpx${ABI} ..."
declare libvpx${ABI}_SUMMARY="$SUMMARY (runtime)"
declare libvpx${ABI}_CONTENTS="usr/bin/cygvpx-${ABI}.dll"
The current test programs do not relink against the unstripped dll,
possibly because of their sizes requiring > 32 bit offsets, so I am no
longer relinking the test programs with the dll, only the distributed
utilities.
$ du libvpx-1.13.1-1.x86_64/{build,inst/usr/bin}/*.{dll,exe}
23M libvpx-1.13.1-1.x86_64/build/cygvpx-8.dll
26M libvpx-1.13.1-1.x86_64/build/test_intra_pred_speed.exe
158M libvpx-1.13.1-1.x86_64/build/test_libvpx.exe
33M libvpx-1.13.1-1.x86_64/build/test_rc_interface.exe
3.3M libvpx-1.13.1-1.x86_64/build/vpxdec.exe
3.5M libvpx-1.13.1-1.x86_64/build/vpxenc.exe
3.4M libvpx-1.13.1-1.x86_64/inst/usr/bin/cygvpx-8.dll
680K libvpx-1.13.1-1.x86_64/inst/usr/bin/vpxdec.exe
700K libvpx-1.13.1-1.x86_64/inst/usr/bin/vpxenc.exe
With codec performance tests disabled, this build also downloads 1.4GB
of test data files from Google under:
https://storage.googleapis.com/downloads.webmproject.org/test_data/libvpx/
which we presumably would prefer not to include in the src package, to
Yeah, including it seems a bad idea.
run tests which take 2.75-3.5 hours out of a 3.75-4.5 hour build, with 5
failures in scallywag CI and 2 failures locally out of 1596 tests, shown
in the attached log, so I have questions into the upstream WebM libvpx
project about those.
Full scallywag logs are available at:
https://cygwin.com/cgi-bin2/jobs.cgi?id=7148=libvpx=Brian+Inglis
Thanks.
I've added this to your packages.
[cygport PATCH] Check for pythonXX-wheel when using python-wheel
The python wheel package is required for building using the python-wheel
cygclass, but nothing in cygport verifies its existence, and the error
from the Python commands themselves aren't particularly helpful either.
To avoid other people wasting the time I just did trying to debug Python
build errors, check if the relevant wheel executable is installed, and
complain if it isn't.
---
cygclass/python-wheel.cygclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/cygclass/python-wheel.cygclass b/cygclass/python-wheel.cygclass
index 4f71639d..3f274b98 100644
--- a/cygclass/python-wheel.cygclass
+++ b/cygclass/python-wheel.cygclass
@@ -111,6 +111,7 @@ do
esac
check_prog_req pip${ver} python${ver//.}-pip
+ check_prog_req wheel-${ver} python${ver//.}-wheel
done
#o* python-wheel.cygclass/PKG_NAMES (python-wheel)
--
2.40.1
