Re: cygport upgrade to use gnupg2/gpg2 if available

2023-11-20 Thread ASSI via Cygwin-apps
Brian Inglis via Cygwin-apps writes:
> After applying the attached patches, which add support for the newer
> gpg2 from gnupg2 if installed, the attached log second chunk shows the
> new keys verified by gpg2 added to lib/src_prep.cygpart
> ___gpg_verify().
>
> Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for
> check and definition and __gpg_sign() for use in gpg signing of Cygwin
> patches and files.


We should just switch to gpg2 an require that, there is no point in
trying to use GPG 1.x anymore.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Re: cygport upgrade to use gnupg2/gpg2 if available

2023-11-20 Thread Brian Inglis via Cygwin-apps

On 2023-11-20 21:51, Brian Inglis via Cygwin-apps wrote:
The attached log first chunk shows that new downloads especially GnuPG and GNU 
packages may be signed with keys not recognized by old gnupg/gpg.
After applying the attached patches, which add support for the newer gpg2 from 
gnupg2 if installed, the attached log second chunk shows the new keys verified 
by gpg2 added to lib/src_prep.cygpart ___gpg_verify().
Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and 
definition and __gpg_sign() for use in gpg signing of Cygwin patches and files.


Not sure what previous lib/src_prep.cygpart patch was generated from, but patch 
from correct sources is attached.


--
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--- /usr/share/cygport/lib/src_prep.cygpart.orig2023-08-07 
09:46:31.0 -0600
+++ /usr/share/cygport/lib/src_prep.cygpart 2023-11-20 23:15:36.349253300 
-0700
@@ -181,12 +181,14 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
 
-   if ! check_prog gpg
+   if check_prog gpg2; then GPG=gpg2; else GPG=gpg; fi
+
+   if ! check_prog $GPG
then
# display notice only once
if ! defined _gpg_not_found_
then
-   inform "gnupg must be installed in order to check 
signatures.";
+   inform "gnupg2 or gnupg must be installed in order to 
check signatures.";
_gpg_not_found_=1
fi
 
@@ -196,7 +198,7 @@ __gpg_verify() {
if [ -f ${_file}.${_sigext} ]
then
inform "${_filetype} signature follows:";
-   gpg --verify ${_file}.${_sigext} ${_file} || true;
+   $GPG --verify ${_file}.${_sigext} ${_file} || true;
fi
 }
 


cygport upgrade to use gnupg2/gpg2 if available

2023-11-20 Thread Brian Inglis via Cygwin-apps

Hi folks,

The attached log first chunk shows that new downloads especially GnuPG and GNU 
packages may be signed with keys not recognized by old gnupg/gpg.


After applying the attached patches, which add support for the newer gpg2 from 
gnupg2 if installed, the attached log second chunk shows the new keys verified 
by gpg2 added to lib/src_prep.cygpart ___gpg_verify().


Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and 
definition and __gpg_sign() for use in gpg signing of Cygwin patches and files.


--
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>>> Preparing gpgme-1.23.1-1.x86_64
*** Info: SOURCE 1 signature follows:
gpg: Signature made 2023 Oct 27 Fri 06:41:07 MDT using ? key ID 26403ADA
gpg: Can't check signature: unknown pubkey algorithm
gpg: Signature made 2023 Nov 14 Tue 17:50:43 MST using ? key ID 19C6C8BD
gpg: Can't check signature: unknown pubkey algorithm

>>> Preparing gpgme-1.23.1-1.x86_64
*** Info: SOURCE 1 signature follows:
gpg: Signature made 2023 Oct 27 Fri 06:41:07 MDT
gpg:using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
gpg: Good signature from "Werner Koch (dist signing 2020)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
gpg: Signature made 2023 Nov 14 Tue 17:50:43 MST
gpg:using EDDSA key AC8E115BF73E2D8D47FA9908E98E9B2D19C6C8BD
gpg: Good signature from "Niibe Yutaka (GnuPG Release Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
--- /usr/share/cygport/lib/pkg_pkg.cygpart.orig 2023-03-08 06:07:57.0 
-0700
+++ /usr/share/cygport/lib/pkg_pkg.cygpart  2023-11-19 21:13:16.879391200 
-0700
@@ -505,7 +505,7 @@ __gpg_sign() {
echo "${2} signature needs to be updated";
rm -f ${1}.sig;
# we 'check_prog gpg' in __pkg_srcpkg()
-   gpg --detach-sign ${1};
+   $GPG --detach-sign ${1};
 }
 
 __squeeze_whitespace() {
@@ -563,7 +563,9 @@ __pkg_srcpkg() {
 
if __arg_bool SIG
then
-   if check_prog gpg
+   if check_prog gpg2; then GPG=gpg2; else GPG=gpg; fi
+
+   if check_prog $GPG
then
__gpg_sign ${spkgdir}/${cygportfile} "CYGPORT SCRIPT";
 
@@ -583,14 +585,15 @@ __pkg_srcpkg() {
__gpg_sign ${spkgdir}/${src_patchfile} "SOURCE 
PATCH";
fi
else
-   inform "gnupg must be installed in order to make 
signatures.";
+   inform "gnupg2 or gnupg must be installed in order to 
make signatures.";
fi
fi
 
cd ${spkgdir%/*};
 
mkdir -p ${distdir}/${PN};
-   __tar ${distdir}/${PN}/${PF}-src.tar.${TAR_COMPRESSION_EXT} 
${spkgdir##*/}/ || error "Source package creation failed"
+   __tar ${distdir}/${PN}/${PF}-src.tar.${TAR_COMPRESSION_EXT} 
${spkgdir##*/}/ \
+   || error "Source package creation failed"
echo;
 
# source package hint
--- /usr/share/cygport/lib/src_prep.cygpart.orig2023-11-19 
18:51:13.284177300 -0700
+++ /usr/share/cygport/lib/src_prep.cygpart 2023-11-19 21:00:35.754036900 
-0700
@@ -181,12 +181,14 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
 
-   if ! check_prog gpg && ! check_prog gpg2
+   if check_prog gpg2; then GPG=gpg2; else GPG=gpg; fi
+
+   if ! check_prog $GPG
then
# display notice only once
if ! defined _gpg_not_found_
then
-   inform "gnupg or gnupg2 must be installed in order to 
check signatures.";
+   inform "gnupg2 or gnupg must be installed in order to 
check signatures.";
_gpg_not_found_=1
fi
 
@@ -195,7 +197,6 @@ __gpg_verify() {
 
if [ -f ${_file}.${_sigext} ]
then
-   [ check_prog gpg2 ] && GPG=gpg2 || GPG=gpg
inform "${_filetype} signature follows:";
$GPG --verify ${_file}.${_sigext} ${_file} || true;
fi


Re: [ITP] gflags 2.2.2

2023-11-20 Thread Jon Turney via Cygwin-apps

On 16/11/2023 23:20, Daisuke Fujimura via Cygwin-apps wrote:

Hello,

[ITP] A new package proposal: gflags

- gflags
- libgflags2.2
- libgflags-devel



SUMMARY: Commandline flags module for C++
HOMEPAGE: https://github.com/gflags/gflags
SRC_URI: https://github.com/gflags/gflags/archive/refs/tags/v2.2.2.tar.gz
LICENSE: BSD-3-Clause



Corresponding Linux/Unix packages are searched:
- https://repology.org/project/gflags/versions

Cygportfile:
- 
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/gflags

Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/6893072156



Looks good.

I've added this to your packages.

The one question I have is about what 'gflags_completions.sh' is for? Is 
this a helper for scripts other packages using gflags might install in 
/etc/bash_completion.d/, or an example? or generally useful?




Re: [PATCH cygport] git.cygclass: Suppress the depth option

2023-11-20 Thread ASSI via Cygwin-apps
Jon Turney via Cygwin-apps writes:
> This could just be named something a little shorter, like
> "GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the
> URI's host?
>
> But I wonder if wouldn't just be better to try with --depth and then
> fallback to without it, if that fails (especially if we can tell it
> failed for that reason).

I was about to say the same thing…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables


Re: [PATCH cygport] git.cygclass: Suppress the depth option

2023-11-20 Thread Jon Turney via Cygwin-apps

On 19/11/2023 02:11, Daisuke Fujimura via Cygwin-apps wrote:

Some git providers do not support smart transport, so specifying the
depth option will result in an error.


Right. This is a bug and needs fixing.

Thanks for the patch.


```
Cloning into ''...
fatal: dumb http transport does not support shallow capabilities
```

Therefore, I suggest adding a variable to suppress the depth option.
(Variable names should be changed to something appropriate according
to the naming convention.)

diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..0aa97a09 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -75,7 +75,12 @@ git_fetch() {
# shallow fetch a ref (master, branch or tag) with --depth=1
# (not allowed for a hash, unless remote is configured to permit
# it with allow*SHA1InWant).
- _depth="--depth 1"
+ _depth=""
+ # git provider does not support smart transport
+ if ! defined GIT_PROVIDER_NOT_SUPPORT_SMART_TRANSPORT


If you're going to add a variable which changes the behaviour of cygport 
like this, it should be documented (by adding an appropriate robodoc 
comment)


This could just be named something a little shorter, like 
"GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the URI's 
host?


But I wonder if wouldn't just be better to try with --depth and then 
fallback to without it, if that fails (especially if we can tell it 
failed for that reason).


(Looking at [1], that seems a better approach than trying to probe the 
URI for smart transport support, which seems problematic)


[1] 
https://stackoverflow.com/questions/9270488/is-it-possible-to-detect-whether-a-http-git-remote-is-smart-or-dumb


What do you think?


+ then
+ _depth="--depth 1"
+ fi
if defined GIT_TAG
then
_depth+=" --branch ${GIT_TAG}"