Re: curl calm issue

2020-11-30 Thread ASSI
Brian Inglis writes:
> The issue is that previous releases were always generated with
> debuginfo, but the latest release also changes debug behaviour to
> strictly check SSL protocol, causing execution issues with users and
> downstreams.

I read upstreams response that this will become the default behaviour
anyway, so I'd not spend any effort on working around this issue unless
you are fairly certain that youi can convince them otherwise.

> I would like to generate the updated release without the behaviour
> change and that appears to also eliminate debuginfo generation.

Then you need to patch out the corrsponding change.  I have not looked
if they lumped it into another define (which would be more difficult) or
if just the configury does an extra define for this error checking (just
undefine it).

> If I need to generate release -2 without debuginfo, how do I avoid
> this issue?

Again, don't.

> Alternatively, could I use separate cygport files to generate the lib
> and bin subpackages without debuginfo, and the devel package with
> debuginfo and the strict SSL protocol check, and how would that work
> with calm?

Please not and no, that sort of nonsense isn't supported by setup anyway.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada


Re: curl calm issue

2020-11-30 Thread Brian Inglis

On 2020-11-30 17:09, cygwin-apps@cygwin.com wrote:

WARNING: homepage:https://curl.haxx.se/ permanently redirects to 
https://curl.se/
ERROR: install packages from source package 'curl' have non-unique current 
versions 7.73.0-1 (curl-debuginfo), 7.73.0-2 (3 others)
ERROR: error while validating merged x86_64 packages for Brian Inglis
SUMMARY: 1 WARNING(s), 2 ERROR(s)


The issue is that previous releases were always generated with debuginfo, but 
the latest release also changes debug behaviour to strictly check SSL protocol, 
causing execution issues with users and downstreams.


I would like to generate the updated release without the behaviour change and 
that appears to also eliminate debuginfo generation.


If I need to generate release -2 without debuginfo, how do I avoid this issue?

Alternatively, could I use separate cygport files to generate the lib and bin 
subpackages without debuginfo, and the devel package with debuginfo and the 
strict SSL protocol check, and how would that work with calm?


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]


Re: [ITP] gengetopt 2.23

2020-11-30 Thread Ken Brown via Cygwin-apps

On 11/30/2020 2:46 PM, Ken Brown via Cygwin-apps wrote:

On 11/29/2020 2:19 PM, Rafel Amer Ramon wrote:


Hi,

[ITP] gengetopt 2.23

Program home page: https://www.gnu.org/software/gengetopt

License: This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

Debian package: https://packages.debian.org/buster/gengetopt

I have uploaded the files to https://github.com/rafelamer/cygwin-gengetopt

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt.cygport
https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23.tar.xz


https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1-src.hint 

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1-src.tar.xz 

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1.hint 

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1.tar.xz 



This looks good.  I just have a few minor comments.

- The SUMMARY should generally not start by repeating the package name.  "A tool 
to write command line option parsing code for C programs" suffices.


- I suggest adding

   HOMEPAGE="https://www.gnu.org/software/gengetopt/;

- The build produces a source patch because of changes to test files:

 >>> Creating source patches
  tests/test_conf_parser_ov2.c |    2 +-
  tests/test_conf_parser_ov3.c |    4 ++--
  tests/test_conf_parser_ov4.c |    2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)

   You can use DIFF_EXCLUDES to avoid this.

- There are two failing tests that you might want to look into at some point.

- I noticed that your github repo contains all the build files.  Once you become 
maintainer, you will be able to push to the official source repo for the package 
(see https://cygwin.com/packaging/repos.html).  This should not contain only the 


should contain

files needed for building the package (i.e., only the cygport file in your 
case).  Pushing to that repo triggers an automatic build (see 
https://cygwin.com/cgi-bin2/jobs.cgi).


I'll go ahead and add you to https://cygwin.com/cygwin-pkg-maint, but I'm not 
sure how to parse your name.  Should it be "Rafel Amer" or "Rafel Amer Ramon" or 
something else?


Thanks for becoming a maintainer.

Ken


Re: [ITP] gengetopt 2.23

2020-11-30 Thread Ken Brown via Cygwin-apps

On 11/29/2020 2:19 PM, Rafel Amer Ramon wrote:


Hi,

[ITP] gengetopt 2.23

Program home page: https://www.gnu.org/software/gengetopt

License: This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

Debian package: https://packages.debian.org/buster/gengetopt

I have uploaded the files to https://github.com/rafelamer/cygwin-gengetopt

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt.cygport
https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23.tar.xz


https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1-src.hint 

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1-src.tar.xz 

https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1.hint 


https://github.com/rafelamer/cygwin-gengetopt/raw/main/gengetopt-2.23-1.x86_64/dist/gengetopt/gengetopt-2.23-1.tar.xz


This looks good.  I just have a few minor comments.

- The SUMMARY should generally not start by repeating the package name.  "A tool 
to write command line option parsing code for C programs" suffices.


- I suggest adding

  HOMEPAGE="https://www.gnu.org/software/gengetopt/;

- The build produces a source patch because of changes to test files:

>>> Creating source patches
 tests/test_conf_parser_ov2.c |2 +-
 tests/test_conf_parser_ov3.c |4 ++--
 tests/test_conf_parser_ov4.c |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

  You can use DIFF_EXCLUDES to avoid this.

- There are two failing tests that you might want to look into at some point.

- I noticed that your github repo contains all the build files.  Once you become 
maintainer, you will be able to push to the official source repo for the package 
(see https://cygwin.com/packaging/repos.html).  This should not contain only the 
files needed for building the package (i.e., only the cygport file in your 
case).  Pushing to that repo triggers an automatic build (see 
https://cygwin.com/cgi-bin2/jobs.cgi).


I'll go ahead and add you to https://cygwin.com/cygwin-pkg-maint, but I'm not 
sure how to parse your name.  Should it be "Rafel Amer" or "Rafel Amer Ramon" or 
something else?


Thanks for becoming a maintainer.

Ken


Re: [ITP] wget2

2020-11-30 Thread Achim Gratz
Hamish McIntyre-Bhatty via Cygwin-apps writes:
> libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin
[…]
> I guess the first warning can be dealt with by removing the (obsolete?)
> option

Nope, last I looked anyway.  That warning is given by a Cygwin specific
part of the toolchain and gets triggered regularly since the underlying
functionality simply can't work on Cygwin.  You can't really avoid it
since the replacment that is mentioned can't be explicitly invoked,
instead the same branch that emits the warning also sets the
corresponding hidden variable.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves


Re: SSH key for David Allsopp

2020-11-30 Thread Jon Turney

On 30/11/2020 17:30, David Allsopp via Cygwin-apps wrote:

Name: David Allsopp
 BEGIN SSH2 PUBLIC KEY 
Comment: "Cygwin Packaging Key"
C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9
 END SSH2 PUBLIC KEY 


Done. Thanks.


SSH key for David Allsopp

2020-11-30 Thread David Allsopp via Cygwin-apps
Name: David Allsopp
 BEGIN SSH2 PUBLIC KEY 
Comment: "Cygwin Packaging Key"
C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9
 END SSH2 PUBLIC KEY 




Re: [ITA] flexdll

2020-11-30 Thread Ken Brown via Cygwin-apps

On 11/30/2020 10:12 AM, David Allsopp via Cygwin-apps wrote:

OCaml has been partially broken on Cygwin64 since 2018. I did some recent
work upstream to fix it and we're expecting OCaml 4.12.0 by the end of the
year to restore full support.

This requires a new release of flexdll (I also maintain upstream for that).
We could do with an updated FlexDLL package before OCaml 4.12.0 is released
to simplify testing on CI servers.

I'd like to offer to adopt the Cygwin flexdll package, therefore.

The changes for 0.39 are trivial:
https://github.com/dra27/cygport-flexdll/commit/2cb2d6787c56eb1367d7aa4588c5
24db92e45492 and test packages are in
https://github.com/dra27/cygport-flexdll/commit/eb544170af8f2a37b7ec8c7eac95
6a47ae9fef4d.


OK, it's all yours.  Please send your SSH key as explained here:

  https://cygwin.com/packaging/key.html#sshkey

Thanks.

Ken


[ITA] flexdll

2020-11-30 Thread David Allsopp via Cygwin-apps
OCaml has been partially broken on Cygwin64 since 2018. I did some recent
work upstream to fix it and we're expecting OCaml 4.12.0 by the end of the
year to restore full support.

This requires a new release of flexdll (I also maintain upstream for that).
We could do with an updated FlexDLL package before OCaml 4.12.0 is released
to simplify testing on CI servers.

I'd like to offer to adopt the Cygwin flexdll package, therefore.

The changes for 0.39 are trivial:
https://github.com/dra27/cygport-flexdll/commit/2cb2d6787c56eb1367d7aa4588c5
24db92e45492 and test packages are in
https://github.com/dra27/cygport-flexdll/commit/eb544170af8f2a37b7ec8c7eac95
6a47ae9fef4d.

Thanks,


David



Re: [ITP] wget2

2020-11-30 Thread Hamish McIntyre-Bhatty via Cygwin-apps
On 27/11/2020 18:28, Brian Inglis wrote:
> On 2020-11-27 10:57, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 24/11/2020 21:06, Brian Inglis wrote:
>>> On 2020-07-08 14:05, Brian Inglis wrote:
 wget2 is the successor of wget supplying a shared library API like
 curl to
 build a modern, fast, multi-threaded, parallel downloader using
 HTTP/2, HTTP
 compression and If-Modified-Since headers; see:
  https://gitlab.com/gnuwget/wget2
 It is currently available on Arch, Debian/Ubuntu, openSUSE,
 Slackware; see:
>>>
>>>  https://repology.org/project/wget2/versions
>>>
>>> Thanks for help getting here and also the upstream folks!
>>>
>>> Please review wget2 repackaged into subpackages available under:
>>>
>>> https://drive.google.com/drive/folders/1VVuC14KuB6uShm4FQL9BuXH0hpLYnIcJ?usp=sharing
>>>
>>>
>>>
>>> Appveyor CI playground repo wget2 jobs:
>>>
>>>  https://cygwin.com/cgi-bin2/jobs.cgi?id=1308
>>>
>>> I have been dogfooding wget2 instead of wget in commands and cron jobs
>>> and it appears considerably faster, but does not support FTP or other
>>> protocols supported by curl or wget, and does not support wget
>>> --retr-symlinks=no option which retrieves symlink contents verbatim
>>> for analysis with readlink e.g. wget ...-latest... and see if it
>>> points to the previous or a newer version.
>>>
>>> For more compatibility info see:
>>>
>>>  https://gitlab.com/gnuwget/wget2/-/wikis/home
>>
>> I had a quick go on 32-bit Cygwin (figuring most people might try
>> 64-bit), and it seems to work fine and be quite quick. I haven't
>> compiled the package but I'll find time soon hopefully - it's small so I
>> guess it doesn't take long.
>
> Thanks - nearly 15min on Appveyor with all the library, devel, and
> debuginfo bits involved.

Okay, I get the following warnings:

configure: WARNING: unrecognized options: --without-lzip

configure: WARNING: *** No working backend for plugin support found

It also reports that there is no HSTS support.

I also get a bunch of warnings (for both 32-bit and 64-bit Cygwin) like:

libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin
libtool: warning: assuming '-no-fast-install' instead
libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin
libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin
libtool: warning: '-no-install' is ignored for x86_64-pc-cygwin
libtool: warning: assuming '-no-fast-install' instead
libtool: warning: assuming '-no-fast-install' instead
libtool: warning: assuming '-no-fast-install' instead

At the end of compilation.

I guess the first warning can be dealt with by removing the (obsolete?)
option, but I'm not sure about the others/if they need fixing. I think
HSTS might be useful to have though.

Finally, I also get a source patch for src/version-text.h even though I
didn't patch it - maybe there needs to be an exception for that file?

All the steps including installing, packaging, and running unit tests
work for me on both 32-bit and 64-bit Cygwin, so it's just the warnings
that I have concerns about really.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature