Re: newer version of mingw64-*-win-iconv ?

[Brian Inglis via Cygwin-apps]

On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 successfully:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if required, and 
do NMU builds and deploys of these?


[Are we really still building 32 bit mingw packages when we dropped support of 
32 bit Windows << 1%?

Steam estimated 32 bit games PCs ~ 0.25% in 2021, and dropped support in 
February.
Surveys don't even bother to report that share nowadays!]

--
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: calm: SPDX licence list data update please

[Brian Inglis via Cygwin-apps]

On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote:

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:


Can we please get the SPDX licence list data updated in calm to 3.24 sometime 
if possible as the licences complained about below have been in 


I thought I wrote about this the last time you asked, but obviously not.


Thought not, but after recent reminder, not so sure now ;^>

This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on that is 
30.0.0, and moving to a later one has some wrinkles, since various pieces of 
interconnected stuff aren't venv'd (yet?).



releases for nearly a year since 3.21:



If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license data, 
ideally we'd have something that read the official SPDX data (ratelimited to 
once per day or something. It looks like maybe this would possible to do by 
feeding our own license list into the module rather than using it's built in 
one, but one could hope for this to be built in already...)


There have been changes in how to specify exceptions using WITH.

It would also be useful if it could also be taught to accept 'LicenseRef-.*' 
identifiers.


Ditto ExceptionRef-.* but that and LicenseRef-.* do not seem to be allowed by 
PEP 639, as they unrealistically expect projects to change existing licences, 
whereas we have to deal with historical reality like Fedora!


So, suggestions on a different module to use, or patches to make this work 
better, or cogent arguments why we should just remove this validation are all 
welcome.


How about if we delegate licence validation to cygport, as someone recently 
offered, or as currently done in calm, with current Cygwin python - add licence 
validation hint to src hint - if not there, calm does it as now?


Would we or should we also allow specifying LICENSE_URI (as I have been doing) 
like PEP 639 license-files, with defaults searched as suggested:


"LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"?

where globs and source paths are allowed as usual in cygport files, and 
directories may match these paths, implicitly including file entries, but no 
file *contents* checked, unless we see a need in future, to generate and 
validate licences.



You can also now remove the exceptions in calm/fixes.py(licmap):


Thanks, will do so.


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: calm: SPDX licence list data update please

[Brian Inglis via Cygwin-apps]

Hi folks,

Can we please get the SPDX licence list data updated in calm to 3.24 sometime if 
possible as the licences complained about below have been in releases for nearly 
a year since 3.21:


On 2024-05-24 02:18, cygwin-no-re...@cygwin.com wrote:

INFO: package 'man-pages-linux': errors in license expression: ['Unknown 
license key(s): Linux-man-pages-1-para, Linux-man-pages-copyleft-var, 
Linux-man-pages-copyleft-2-para']


https://github.com/spdx/license-list-XML/releases/tag/v3.21

https://github.com/spdx/license-list-data/releases

https://github.com/spdx/license-list-data/tree/main/json
https://github.com/spdx/license-list-data/tree/main/jsonld

https://spdx.github.io/license-list-data/

If these are handled by PEP-0639/pip/NexB/SPDX license-expression, possibly 
someone could package it and license-list-data and add to calm prereqs?


If not, perhaps I could be of some help if I knew requirements?

You can also now remove the exceptions in calm/fixes.py(licmap):

https://cygwin.com/git/?p=cygwin-apps/calm.git;a=blob;f=calm/fixes.py;h=1f67d131d49d68c93f96548af1947dd405b4f743;hb=HEAD#l150

for my packages dash, cpuid, units, grep, gzip, readline, unifont, bison, wget, 
libgcrypt, mingw64-*-/libidn, mingw64-*-/libidn2, mingw64-*-/curl, 
man-pages-{linux,posix}, vttest, tz{code,data}:


BSD-3-Clause AND GPL-2.0-or-later
dash/dash.cygport:LICENSE="BSD-3-Clause AND GPL-2.0-or-later"

GPL-2.0-or-later
cpuid/cpuid.cygport:LICENSE=GPL-2.0-or-later

GPL-3.0-or-later
units/units.cygport:LICENSE="GPL-3.0-only AND GFDL-1.3-only"

GPL-2.0-or-later
grep/grep.cygport:LICENSE=GPL-2.0-or-later
gzip/gzip.cygport:LICENSE=GPL-2.0-or-later
readline/readline.cygport:LICENSE=GPL-3.0-or-later

GPL-2.0-or-later WITH Font-exception-2.0 OR OFL-1.1,
unifont/unifont.cygport:LICENSE="(GPL-2.0-with-font-exception OR OFL-1.1) AND 
GPL-2.0-or-later AND LicenseRef-Unifoundry-Unifont-Public-Domain"


**I will update Unifont as I see GPL...-exception is now deprecated**
and 16 is in beta preview.

Can we just split these long quoted strings or do we need \ line continuations?
And does anyone know if there is a convention for splitting licence expressions 
in comments across lines?


GPL-3.0-or-later
bison/bison.cygport:LICENSE=GPL-3.0-or-later
wget/wget.cygport:LICENSE=GPL-3.0-or-later

LGPL-2.1-or-later AND GPL-2.0-or-later
libgcrypt/libgcrypt.cygport:LICENSE="LGPL-2.1-or-later AND GPL-2.0-or-later AND 
(GPL-2.0-only OR BSD-3-Clause) AND BSD-3-Clause"


(LGPL-3.0-or-later OR GPL-2.0-or-later) AND GPL-3.0-or-later,
libidn/libidn.cygport:LICENSE="LGPL-3.0-or-later AND GPL-2.0-or-later AND 
GPL-3.0-or-later AND GFDL-1.3-or-later"

libidn/mingw64-i686-libidn/mingw64-i686-libidn.cygport:LICENSE=LGPLv3+/GPLv2+/GPLv3+/GFDLv1.3+
libidn/mingw64-x86_64-libidn/mingw64-x86_64-libidn.cygport:LICENSE="LGPL-3.0-or-later 
AND GPL-2.0-or-later AND GPL-3.0-or-later AND GFDL-1.3-or-later"


(LGPL-3.0-or-later OR GPL-2.0-or-later) AND GPL-3.0-or-later AND 
Unicode-DFS-2016,
libidn2/libidn2.cygport:LICENSE="LGPL-3.0-or-later AND GPL-2.0-or-later AND 
GPL-3.0-or-later AND Unicode-TOU AND Unicode-DFS-2016"
libidn2/mingw64-i686-libidn2/mingw64-i686-libidn2.cygport:LICENSE="LGPL-3.0-or-later 
AND GPL-2.0-or-later AND GPL-3.0-or-later AND Unicode-TOU AND Unicode-DFS-2016"
libidn2/mingw64-x86_64-libidn2/mingw64-x86_64-libidn2.cygport:LICENSE="LGPL-3.0-or-later 
AND GPL-2.0-or-later AND GPL-3.0-or-later AND Unicode-TOU AND Unicode-DFS-2016"


curl
curl/curl.cygport:LICENSE=curl
curl/mingw64-i686-curl/mingw64-i686-curl.cygport:LICENSE=curl
curl/mingw64-x86_64-curl/mingw64-x86_64-curl.cygport:LICENSE=curl

Linux-man-pages-copyleft
man-pages-linux/man-pages-linux.cygport:LICENSE="MIT \
man-pages-posix/man-pages-posix.cygport:LICENSE=Linux-man-pages-copyleft

BSD-Source-Code
vttest/vttest.cygport:LICENSE=BSD-Source-Code

BSD-3-Clause AND Public-Domain
tzdata/tzdata.cygport:LICENSE=LicenceRef-IANA-TZ-Public-Domain
tzcode/tzcode.cygport:LICENSE=LicenceRef-IANA-TZ-Public-Domain

--
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: [ITA] dateutils

[Brian Inglis via Cygwin-apps]

On 2024-05-21 09:57, Brian Inglis via Cygwin-apps wrote:

On 2024-05-21 07:17, Jon Turney via Cygwin-apps wrote:

On 17/05/2024 06:43, Brian Inglis via Cygwin-apps wrote:

Date manipulation utilities
I would like to adopt the above orphaned package.

Thanks.
I added this to your packages.

https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground

Please cleanup all the commented out detritus.


Sure!

What is the reasoning for changing SRC_URI to point to github?  The project 
homepage still points to bitbucket.org for downloads.


They provide the same release tarball on github, and README on both sites state 
that "Dateutils are hosted primarily on github:", so I see no reason to use what 
appears to be the legacy repo at another site, although I would treat them as 
project mirrors if possible.
Looking at latest release downloads they are 50/50 across both sites so far, 
although the signature downloads from github are much higher; see:


 https://bitbucket.org/hroptatyr/dateutils/downloads/

https://somsubhra.github.io/github-release-stats/?username=hroptatyr=dateutils=1_page=100



"*** Warning: DEPEND is deprecated, use BUILD_REQUIRES instead."

Scallywag runs:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils
The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?

Can you share the reasoning that lets your reach that conclusion from:

FAIL: tzmap_check_02.ctst


The original failure log messages from xargs complained about lack of 
environment space.


The build directory should be available as an artifact which may contain more 
detailed information on the failure.


I wish - the test runner is very tidy - just the trs and log.


Have you established that this failure is not a regression?


Running standalone from test dir with:

 $ make --trace TESTS=tzmap_check_02.ctst V=1 check

passes with all the usual messages - attached.


Error message in attached log is:

xargs: environment is too large for exec

consistent across local and scallywag builds.

--
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$ find "${root}/lib" "${TZMAP_DIR}/../lib" -name '*.tzmcc' | xargs "${TZMAP}" 
check
xargs: environment is too large for exec
$? 1
FAIL tzmap_check_02.ctst (exit status: 1)

Re: libtool can't build shared library unless -no-undefined specified

[Brian Inglis via Cygwin-apps]

On 2024-05-21 07:18, Jon Turney via Cygwin-apps wrote:

On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote:

On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:

On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:

Trying to update dateutils, autotools build fails with:
libtool: error: can't build x86_64-pc-cygwin shared library unless 
-no-undefined is specified

Suggestions for overrides or fixes?
Tried:
LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"
CYGCONF_ARGS="
  --enable-contrib
  --enable-tzmap-fetch
  lt_no_undefined_flag=--no-undefined
  no_undefined_flag=--no-undefined
You and I discussed this a few years ago in connection with curl.  The 
solution there, and in most similar cases, is to add -no-undefined to the 
appropriate lib*_la_LDFLAGS variable(s) in Makefile.am.  See


Had to patch into lib AM_LDFLAGS variable, then found out that library was not 
for use in open source packages, but only required to link with a (missing) 
proprietary MatLab module, so dropped the config --enable-contrib option!


Yeah, building stuff for Cygwin often requires adding this flag in the 
appropriate places, to say "yes, I really do want a shared library".

https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode

-no-undefined
Declare that output-file does not depend on any libraries other than
the ones listed on the command line, i.e., after linking, it will not
have unresolved symbols. Some platforms require all symbols in shared
libraries to be resolved at library creation (see Inter-library
dependencies), and using this parameter allows libtool to assume that
this will not happen.
Note that because this flag doesn't do anything for non-PE targets, it's (a) 
always safe to upstream, and (b) doesn't actually prevent development from 
unwittingly introducing unresolved symbols.


In that case, could we ask Bruno to add into gnulib somewhere appropriate?


This should probably be mentioned in the FAQ item on PE linkage peculiarities.


In libtool info?

--
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: [ITA] bash-completion/-devel

[Brian Inglis via Cygwin-apps]

On 2024-05-21 07:19, Jon Turney via Cygwin-apps wrote:

On 03/05/2024 14:40, Jon Turney via Cygwin-apps wrote:

On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which was 
adopted by Eric but not updated since Yaakov.


Thanks.

I added this to your packages.

I guess I need to ask eblake if he wants to orphan his packages, since he 
seems to be no longer active...

Excluding co-maintained packages, the list is:


$ grep 'Eric Blake' cygwin-pkg-maint | grep -v '/'
bashdb   Eric Blake
cppi Eric Blake
cvsps    ORPHANED (Eric Blake)
cvsutils Eric Blake
gperf    Eric Blake
libsigsegv   Eric Blake
sharutils    Eric Blake


I looked at cvsutils and sharutils and concluded that they were unlikely to be 
upgraded upstream, although you can add my name to those if you wish.


I do not remember looking at the others, although some may be in a similar 
state, or gone walkabout, and I did not have sufficient interest to recall.


--
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: [ITA] dateutils

[Brian Inglis via Cygwin-apps]

On 2024-05-21 07:17, Jon Turney via Cygwin-apps wrote:

On 17/05/2024 06:43, Brian Inglis via Cygwin-apps wrote:

Date manipulation utilities
I would like to adopt the above orphaned package.

Thanks.
I added this to your packages.

https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground

Please cleanup all the commented out detritus.


Sure!

What is the reasoning for changing SRC_URI to point to github?  The project 
homepage still points to bitbucket.org for downloads.


They provide the same release tarball on github, and README on both sites state 
that "Dateutils are hosted primarily on github:", so I see no reason to use what 
appears to be the legacy repo at another site, although I would treat them as 
project mirrors if possible.
Looking at latest release downloads they are 50/50 across both sites so far, 
although the signature downloads from github are much higher; see:


https://bitbucket.org/hroptatyr/dateutils/downloads/

https://somsubhra.github.io/github-release-stats/?username=hroptatyr=dateutils=1_page=100



"*** Warning: DEPEND is deprecated, use BUILD_REQUIRES instead."

Scallywag runs:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils
The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?

Can you share the reasoning that lets your reach that conclusion from:

FAIL: tzmap_check_02.ctst


The original failure log messages from xargs complained about lack of 
environment space.


The build directory should be available as an artifact which may contain more 
detailed information on the failure.


I wish - the test runner is very tidy - just the trs and log.


Have you established that this failure is not a regression?


Running standalone from test dir with:

$ make --trace TESTS=tzmap_check_02.ctst V=1 check

passes with all the usual messages - 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$ find "${root}/lib" "${TZMAP_DIR}/../lib" -name '*.tzmcc' | xargs "${TZMAP}" 
check
$? 0
PASS tzmap_check_02.ctst (exit status: 0)
:test-result: PASS
:global-test-result: PASS
:recheck: no
:copy-in-global-log: no
===
   dateutils 0.4.11: test/test-suite.log
===

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

[ITA] dateutils

[Brian Inglis via Cygwin-apps]

Date manipulation utilities

Dateutils are a bunch of tools that revolve around fiddling with
dates and times on the command line with a strong focus on use cases
that arise when dealing with large amounts of financial data.

For more information see the project home pages:

http://www.fresse.org/dateutils
https://github.com/hroptatyr/dateutils

I would like to adopt the above orphaned package.

Below are links to the existing package, build repo, scallywag runs,
and changes.

Existing package:

https://cygwin.com/packages/summary/dateutils-src.html

https://cygwin.com/packages/summary/dateutils.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils

The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?

Changes since the last Cygwin release:

https://github.com/hroptatyr/dateutils/compare/v0.4.0...v0.4.11

-- 

Re: libtool can't build shared library unless -no-undefined specified

[Brian Inglis via Cygwin-apps]

On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:

On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless 
-no-undefined is specified


Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
  --enable-contrib
  --enable-tzmap-fetch
  lt_no_undefined_flag=--no-undefined
  no_undefined_flag=--no-undefined


You and I discussed this a few years ago in connection with curl.  The solution 
there, and in most similar cases, is to add -no-undefined to the appropriate 
lib*_la_LDFLAGS variable(s) in Makefile.am.  See


   https://cygwin.com/pipermail/cygwin-apps/2020-August/040411.html


Thanks for the reminder Ken,

You must have a great memory and/or search strategy.
Even checking back on curl and github I have zero memory of making this patch, 
and it being accepted upstream, but this should prompt me to remember to search 
wider in my email hierarchy, and in my own package repo clones and directories 
for patches.

Now your response is starred in my email.
Perhaps I worked contract gigs too long, my memory compressor kicked in, and 
swapped that out to external storage (here!)

Hoping this will perhaps hammer a nail in my memory to hang that info on.

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

libtool can't build shared library unless -no-undefined specified

[Brian Inglis via Cygwin-apps]

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless -no-undefined 
is specified


Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
 --enable-contrib
 --enable-tzmap-fetch
 lt_no_undefined_flag=--no-undefined
 no_undefined_flag=--no-undefined
"

--
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: calm: ncurses untest/vault previous version

[Brian Inglis via Cygwin-apps]

On 2024-05-13 09:32, Jon Turney via Cygwin-apps wrote:

On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the
previous version in the recommended format 6.4+20240330-1 was older
than prev:

6.4-20231230


So, this would be a bug, if that's actually what happened, because
6.4+20240330 is definitely greater than 6.4 (under the "if all comparison chunks 
are equal, the string with any suffix remaining is the greater" clause of the 
comparison rule).


What actually seems to have happened is that 6.4+20240330 was still
marked as 'test', and so removed by the "packages labelled test: are
expired when a superseding non-test version exists" logic.


Thanks Jon,

Missed that focusing on the versions not the labels in setup.ini.


(Yeah, calm should probably be a bit more verbose about the reasons why
it's vaulting things in the report)


I can vault the old versions but could someone please unvault 6.4+20240330-1?


Sure, I'll do that.

Do you want me to remove the test label from 6.4+20240330, or turn on
keep-superseded-test for this package?


Sorry, I should have noticed and untest-ed that immediately before 6.5!
Please remove test label to unvault as "prev" not test.
I've been running with it since released as test, until 6.5, and it is the final 
6.4 we made available, in case anyone has issues with 6.5.


--
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: calm: ncurses untest/vault previous version

[Brian Inglis via Cygwin-apps]

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the previous version 
in the recommended format 6.4+20240330-1 was older than prev:


6.4-20231230
6.1-1.20190727
6.0-12.20171125
6.0-11.20170617
6.4-20240120

I can vault the old versions but could someone please unvault 6.4+20240330-1?

On 2024-05-12 07:47, cygwin-no-re...@cygwin.com wrote:

INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1-src.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1-src.tar.xz
INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1.tar.xz
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114-src.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114-src.tar.xz
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4-3.20230114.tar.xz
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4+20240330-1.hint
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4+20240330-1.tar.xz
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4-3.20230114.hint
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4-3.20230114.tar.xz
SUMMARY: 36 INFO(s)


--
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: calm: vaulting ancient unifont

[Brian Inglis via Cygwin-apps]

On 2024-05-06 09:27, Jon Turney via Cygwin-apps wrote:

On 04/05/2024 20:21, Brian Inglis via Cygwin-apps wrote:

Thanks Jon? - yay!


Right, I deployed some changes to calm which will gradually let us get rid of 
the "old-style" of obsoletion (where, as here, the old name of a package (i.e. 
font-unifont-misc, font-unifont-ttf) continues to exist with a category of 
_obsolete and requires: its replacement)


(cygport stopped generating these some time ago (0.34.1, 2022), but they've been 
lingering around indefinitely, because in some cases it's only the existence of 
these packages which currently records the fact of the obsoletion)



Since someone's bound to get the wrong end of the stick: This doesn't mean 
package maintainers should change anything.


And just to reiterate: As a principle, every version of a package must contain 
complete instructions for upgrading to it. So, it is almost never correct to go 
"I'll remove these OBSOLETE instruction after one package release with them, 
since they've already happened everywhere..."


On 2024-05-04 09:48, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org 
wrote:

INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint
INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz

SUMMARY: 8 INFO(s)


Anyhow, double checking that the "right thing" happened here, I notice that 
'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, especially 
since it contains the expected .dbg files etc.


Brian,

Are you sure that's right?


It appears not!
My reasoning was that as unifont-viewer was split out from unifont-fonts, 
unifont-viewer-debuginfo would be generated, but it appears that is not how that 
works.
Is there any way to make that work, or should I just drop it in the next 
release, or a new -RELEASE?


--
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: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis via Cygwin-apps]

On 2024-05-06 09:52, Jon Turney via Cygwin-apps wrote:

On 01/05/2024 17:48, Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:
Some package upstreams offer only checksums, for example .sha512sum, 
.sha256sum, for verification rather than gpg signatures, for example

.asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed
on download to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;

use coreutils cksum as it supports all modern and legacy checksums and formats.



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


Two similar independent implementations mean it would be a good idea to add 
the feature!


Mine preferred cksum as being the most general approach, while not worrying or 
knowing too much about ancient sums, although your implementation is better, 
that is, works properly on those.


Mine also preferred sha*sum file types, while still allowing prefixes only 
without sum, not enumerating them all in the unpack() case, and respecting the 
cksum crc default.


I guess this makes sense as a part of the fetch operation, in those cases where 
upstream provides signatures or checksums.


I will retry incorporating Achim's approach so hopefully we can both retire our 
local cygport patches.


I would also appreciate other comments or feedback to my reply to Achim's NAK on 
my patch for `gpgv` replacing `gnupg2 --verify`?


But as briefly discussed in [1], independently of that it would also be a good 
idea for cygport to specify it's own checksum file, which is incorporated into 
the source package, and verified at build prep time.


As in Fedora RPM package `sources` BSD-style sum prefix, for example (one line):

https://src.fedoraproject.org/rpms/bash-completion/blob/rawhide/f/sources
SHA512 (bash-completion-2.13.0.tar.xz) = 
7c65fea599a25c2c9d6ef300a9cc2d5fbabd0bcc9e09fe32bb706d3398936f40501171f03280f042465bc0d9aca4b1b53c2c13a99bbdfb6fe916767a267158af


or also in the source package for cygport and each source file included, as in 
Debian dsc, for example:


https://deb.debian.org/debian/pool/main/b/bash-completion/bash-completion_2.13.0-1.dsc
Checksums-Sha1:
 0c045cc06b57bbe8945bc6c4ea8f2b52f1285903 484155 
bash-completion_2.13.0.orig.tar.gz
 66f10d161e71c0725a61d5bde1c6b89f9bdb61e3 17840 
bash-completion_2.13.0-1.debian.tar.xz

Checksums-Sha256:
 6c1cc04bb506e7ba6bd7bb3c7c6f6ad2b46e6198e8ef4c88139597250601 484155 
bash-completion_2.13.0.orig.tar.gz
 d2de6c33d14843da64e4b20e6330c14079b2c73f04c9b4c544d6435930003a67 17840 
bash-completion_2.13.0-1.debian.tar.xz

Files:
 93527b12850a781744e3f335f904bdf1 484155 bash-completion_2.13.0.orig.tar.gz
 a831ae35940daf95016fce1b655955a1 17840 bash-completion_2.13.0-1.debian.tar.xz

(Since this would protect against such screw ups, help with build 
reproducibility, and defend against supply chain attacks on upstream)


[1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html


Coreutils `cksum` does BSD-style checksums, although I would prefer sha256 sums 
for brevity and consistency with setup.ini, and base64 encoding rather than hex 
to shorten the checksum representation, in recent coreutils.


We all have SSH keys, which I also have as a GPG key, could we also use them for 
signing source packages?
Calm could validate ours and checksums, and re-sign with Cygwin key, which setup 
could validate.

Could osslsigncode have any application here?

--
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

RFC: postinstall fontconfig cache changes

[Brian Inglis via Cygwin-apps]

Hi folks,

Since Yaakov added the fontconfig cache postinstall script, it has been 
selecting only fonts created by 'Microsoft Corp' and (recently?) matching 
'*.ttf' (lower case only) for whatever reasons?


I have been running my own attached local fontconfig cache postinstall script, 
with some tweaks, such as putting my symlinks into font directory 'windows' 
instead of fontconfig package's 'microsoft', using `cygpath -UW` so the symlinks 
to Windows/Fonts created survive changes I made to cygdrive over the years, 
adding .ttf fonts not created by 'Microsoft Corp' including those only 
'Microsoft supplied', original Windows .TTF (uppercase) fonts installed with the 
system, .ttc font collections which are supported by recent fontconfig, and .otf 
OpenType fonts provided with newer font packages, as Pango and Harfbuzz do not 
appear to support some recent TrueType hinting changes.


I also have to clean up the cache directory, as it sometimes got to *many* 1000s 
of cache files, taking up GB, a known but unsolved? (may now be fixed) issue 
with "broken" [see NEWS] font cache handling, whereas after resetting it has 
only dozens of cache files taking a dozen MB, created in ~10s for ~3600 fonts, 
from Windows, packages, and local downloads and installs.


I would like to request consideration for adding all Windows fonts of supported 
types of any case to the cache every startup.


--
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#!/bin/dash
# zp_l_fontconfig_cache.dash - update Windows non-MS Corp ttf, TTF, ttc, and 
otf font links and rebuild font cache

winfontsdir=/usr/share/fonts/windows
cache=/var/cache/fontconfig
mscorp='Microsoft Corp'
win="$(cygpath -UW)/Fonts"  # ln to /proc/cygdrive in case mount changes 
later

/bin/mkdir -p $winfontsdir

# remove any broken links (-L -type l together)
/usr/bin/find -L $winfontsdir -type l -delete

# find Windows .TTF, .otf, .ttc and non-MS Corp .ttf fonts and link between 
fonts dirs
# Notes:
# system 
# DUBAI-*, MTEXTRA, others are 'Microsoft supplied font';
# all *.TTF are 'Microsoft Corp'; some are also 'Microsoft supplied font';
# .../Fonts may have Deleted subdirectory;
# grep -L returns names of files with no pattern matches;
# fontconfig handles ttc TrueType collections and otf OpenType fonts
/usr/bin/find "$win" -maxdepth 1 -type f\
   \(  -name '*.ttf' -exec /bin/grep -FaL "$mscorp" '{}' + \)   \
-o \(  -name '*.TTF' -print \)  \
-o \( -iname '*.ttc' -print \)  \
-o \( -iname '*.otf' -print \)  | \
while read f
do
[ -e "$winfontsdir/${f##*/}" ] || /bin/ln -st $winfontsdir/ "$f"
done

/usr/bin/mkfontscale$winfontsdir
/usr/bin/mkfontdir  $winfontsdir

# get cache file suffix currently -le64.cache-9 from latest fontconfig dll
dll=$(/bin/ls -rv /bin/cygfontconfig-*.dll | /usr/bin/head -n1)
suf=$(/bin/grep -Eao '[[:graph:]]*\.cache-[[:graph:]]+' $dll)

# cleanup cache every install - can become 100k+ files using GBs
/bin/rm -f $cache/*$suf
/usr/bin/find $cache -iname "*$suf" -delete

# reset and cache system dirs
/usr/libexec/fc-cache-1 -rs || :

# ensure TAG later for cleanup cron job
/usr/bin/touch -c $cache/CACHEDIR.TAG

lynx 2.9.1 available

[Brian Inglis via Cygwin-apps]

Package lynx seems to have moved on from lynx.browser.org which is outdated at 
2.8.8, to lynx.invisible-island.net where 2.9.1 is the latest stable release 
following on from 2.9.0:


https://lynx.invisible-island.net/index.html

https://lynx.invisible-island.net/lynx.html

https://lynx.invisible-island.net/release/index.html

https://invisible-island.net/archives/lynx/tarballs/\
lynx2.9.1.tar.bz2{,.asc}

https://github.com/ThomasDickey/lynx-snapshots/tags

--
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: calm: vaulting ancient unifont

[Brian Inglis via Cygwin-apps]

Thanks Jon? - yay!

On 2024-05-04 09:48, cygwin-no-re...@cygwin.com wrote:

INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint
INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz
SUMMARY: 8 INFO(s)


--
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: [ITA] bash-completion/-devel

[Brian Inglis via Cygwin-apps]

On 2024-05-03 07:40, Jon Turney via Cygwin-apps wrote:

On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which was 
adopted by Eric but not updated since Yaakov.


Thanks.

I added this to your packages.


Thanks Jon

I guess I need to ask eblake if he wants to orphan his packages, since he seems 
to be no longer active...


Looks like he's busy with Austin Group POSIX + IEEE update plus work

Below are links to existing source packages, build repos, scallywag runs, and 
updated package info.


I would like to further improve the sdesc and ldesc provided to reflect that 
completions are provided for thousands of commands and their options and 
arguments.



Bash Completions and development

Existing source package:

https://cygwin.com/packages/summary/bash-completion-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground


A few comments:



DEPEND="automake dejagnu make screen"    # tcllib
BUILD_REQUIRES="$DEPEND"


Just set BUILD_REQUIRES.

I assume the comment about tcllib means something to someone. :)


Checked Fedora spec for "advice" - required for testing - n/a on Cygwin


src_test() {
    cd $B
# For some tests involving non-ASCII filenames
    export LANG=C.UTF-8
    export -f cygtest
# This stuff borrowed from dejagnu-1.4.4-17 (tests need a terminal)
    tmpfile=$(mktemp bash-completion.screen.XX.tmp)
#   cygtest


At first glance, because this is commented out, I thought "so this doesn't run 
tests at all"


Maybe remove the commented out line, and write a comment saying something like 
"run tests under screen, since they need a terminal"



    screen -D -m bash -c '( cygtest ; echo $? ) >'$tmpfile
    cat $tmpfile
 result=$(tail -n 1 $tmpfile)


Also borrowed from Fedora spec.
Plan to do more comments and cleanup before merging to master.
They also had a ChangeLog generation problem so reported upstream and made my 
own; they are trying a fix and update or may have a newer package release.


This cleverness to propagate the exit code is probably also worthy of comment, 
since I had to think about it for a few minutes before I realized what it was 
doing...


Perhaps should remove tmpfile here?


Must have deleted instead of commenting out!


    return $result
}


--
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: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis via Cygwin-apps]

On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:

Some package upstreams offer only checksums, for example .sha512sum, .sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.



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


Two similar independent implementations mean it would be a good idea to add the 
feature!


Mine preferred cksum as being the most general approach, while not worrying or 
knowing too much about ancient sums, although your implementation is better, 
that is, works properly on those.


Mine also preferred sha*sum file types, while still allowing prefixes only 
without sum, not enumerating them all in the unpack() case, and respecting the 
cksum crc default.


--
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: [PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

[Brian Inglis via Cygwin-apps]

On 2024-04-30 23:50, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:

Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
single operation gpg verification helper designed for use in scripts
instead of gpg2 --verify: see 'info gpg2 helper gpgv'


NAK. This tool doesn't check for expired keys and also searches for
keys in different places, so you'd have to change your setup.  More
specifically you'd either have to explicitly trust all keys you want to
check (not going to happen) or use a "--keyring" argument to force it to
use the pubring.


Questioning FMI but not disagreeing with your decision ;^>

Not seeing any key issues as my pubring.gpg is symlinked as trustedkeys.gpg?

Although scallywag runs can not even check keys, so what can we do about that?

2024-04-28T21:41:01.4042065Z >>> Preparing ncurses-6.5+20240427-1.x86_64
2024-04-28T21:41:01.4235798Z *** Info: SOURCE 1 signature follows:
2024-04-28T21:41:01.4407160Z gpg: directory '/home/runneradmin/.gnupg' created
2024-04-28T21:41:01.4508023Z gpg: keybox '/home/runneradmin/.gnupg/pubring.kbx' 
created

2024-04-28T21:41:01.4775748Z gpg: Signature made Sat, Apr 27, 2024  8:27:29 PM 
UTC
2024-04-28T21:41:01.4776513Z gpg:using RSA key 
19882D92DDA4C400C22C0D56CC2AF4472167BE03

2024-04-28T21:41:01.4784503Z gpg: Can't check signature: No public key

Other advantage is not seeing Eric Blake and others' pictures pop up ;^>

I tested with all my cached signed upstream package downloads and compared the 
logs from gpg2 --verify and gpgv2, so what benefit is reporting trust level 
"[unknown]" and expired keys from cygport, and what are you meant to do about 
expired keys for upstream package signers?


[While checking also came across keys from 1998 with my dialup email address!]

--
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

[PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis via Cygwin-apps]

From: "Brian Inglis" 

Some package upstreams offer only checksums, for example .sha512sum, .sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.

define __sum_verify() after __gpg_verify();
add to readonly function definition list
unpack(): skip files matching *.*sum
__src_prep():
define file types or prefixes in variable sum_exts;
in src files loop after __gpg_verify():
match file checksum type and call __sum_verify()

Signed-off-by: Brian Inglis 
---
 lib/src_prep.cygpart |   56 
++-
 1 file changed, 55 insertions(+), 1 deletion(-)

--- lib/src_prep.cygpart2024-01-15 05:09:23.0 -0700
+++ lib/src_prep.cygpart2024-04-30 11:41:01.218878400 -0600
@@ -88,6 +88,7 @@ unpack() {
# determine correct source decompression command
case ${unpack_file_path} in
*.asc|*.md5|*.sig|*.sign)  continue ;;
+   *.*sum)continue ;;
*.tar.lrz)
check_prog_req lrzuntar lrzip
unpack_cmd="lrzuntar"
@@ -200,6 +201,43 @@ __gpg_verify() {
fi
 }
 
+__sum_verify() {
+   local _file=${1#${DISTDIR}/};
+   local _filedesc=${2};
+   local _filetype=${3};
+   local _sum=${3%sum};
+
+   if ! check_prog cksum
+   then
+   # display notice only once
+   if ! defined _cksum_not_found_
+   then
+   inform "cksum must be installed in order to check 
checksums.";
+   _cksum_not_found_=1
+   fi
+
+   return 0;
+   fi
+
+   # {b2,b2b}{,sum} -> blake2b; ck{,sum} -> crc; {,sum} -> bsd
+   [ -z "${_sum}" ]&& _sum=${_sum:-bsd}
+   [ "b2" = "${_sum}" ]&& _sum=blake2b
+   [ "b2b" = "${_sum}" ]   && _sum=blake2b
+   [ "ck" = "${_sum}" ]&& _sum=crc
+
+   if defined DISTDIR && [ -d ${DISTDIR} ] && [ -f ${DISTDIR}/${_file} ]
+   then
+   cd ${DISTDIR}
+   inform "${_filedesc} ${_filetype} checksum verification 
follows:";
+   if [ "${_sum}" = "crc" ] || [ "${_sum}" = "bsd" ] || [ 
"${_sum}" = "sysv" ]
+   then
+   cksum -a ${_sum} ${_file%.${_filetype}} || true;
+   else
+   cksum -a ${_sum} -c ${_file} || true;
+   fi
+   fi
+}
+
 __mkdirs() {
cd ${top};
mkdir -p ${srcdir} ${origsrcdir} ${B} ${D} ${T} ${configdir} ${logdir} 
${distdir} ${patchdir} ${spkgdir};
@@ -298,6 +336,10 @@ __src_prep() {
local src_pkg;
local tar_patch;
local n=1;
+   local sum_exts="sha512 sha384 sha256 sha224 b2 b2b blake2b sm3 sha1 md5 
ck crc bsd sysv";
+   # prefer newer stronger keys for faster lookup
+   # blake2b bsd crc md5 sha1 sha224 sha256 sha384 sha512 sm3 sysv
+   # {b2,b2b}{,sum} -> blake2b; ck{,sum} -> crc; {,sum} -> bsd
 
cd ${top};
 
@@ -328,6 +370,18 @@ __src_prep() {
__gpg_verify ${src_pkg} "SOURCE $((n++))" 
${sigext};
fi
done
+   for sigext in ${sum_exts} ''# final entry is BSD .sum -> ''
+   do
+   if [ "${src_pkg}" != "${src_pkg%.${sigext}sum}" ]
+   then
+   __sum_verify ${src_pkg} "SOURCE $((n++))" 
"${sigext}sum";
+   break;
+   elif [ "${src_pkg}" != "${src_pkg%.${sigext}}" ]  # 
fail if '' unless *.
+   then
+   __sum_verify ${src_pkg} "SOURCE $((n++))" 
"${sigext}";
+   break;
+   fi
+   done
done
 
for src_patch in ${_src_orig_patches}
@@ -510,4 +564,4 @@ __src_prep() {
 }
 
 readonly -f __cpio_gz_extract __gem_extract __srpm_extract unpack \
-__gpg_verify __mkdirs cygpatch __src_prep
+__gpg_verify __sum_verify __mkdirs cygpatch __src_prep

[PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

[Brian Inglis via Cygwin-apps]

From: "Brian Inglis" 

Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
single operation gpg verification helper designed for use in scripts
instead of gpg2 --verify: see 'info gpg2 helper gpgv'

__gpg_verify(): use gpgv2 not gpg2 --verify

Signed-off-by: Brian Inglis 
---
 lib/src_prep.cygpart |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/lib/src_prep.cygpart  2024-01-15 05:09:23.0 -0700
+++ b/lib/src_prep.cygpart  2024-04-30 01:49:54.294030400 -0600
@@ -181,7 +181,7 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
 
-   if ! check_prog gpg2
+   if ! check_prog gpgv2
then
# display notice only once
if ! defined _gpg_not_found_
@@ -196,7 +196,7 @@ __gpg_verify() {
if [ -f ${_file}.${_sigext} ]
then
inform "${_filetype} signature follows:";
-   gpg2 --verify ${_file}.${_sigext} ${_file} || true;
+   gpgv2 ${_file}.${_sigext} ${_file} || true;
fi
 }
 

Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Brian Inglis via Cygwin-apps]

On 2024-04-30 15:07, Christian Franke via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
The new script uses the SPDX webpages to create the license file. I didn't 
find a usable single license list at https://github.com/spdx


As usual, it is easier if you clearly state the purpose of the file you want, 
and its desired properties, like data content, format, etc.



What about:
https://spdx.github.io/license-list-data/


This is apparently a draft version of https://spdx.org/licenses/index.html which 
is used by the script to generate the local license file.


Strip out the table entries and create what you want with a command or script.


and everything under:
https://github.com/spdx/license-list-data



I didn't find a single file which lists the licenses there.


GH does not always make access easy, with its limited online displays and fixed 
display orders, and searches return a lot of junk, without easy access to better 
searching in context, but try:


https://github.com/spdx/license-list-data/blob/main/licenses.md

which also has xrefs to the text files; also there are:

https://github.com/spdx/license-list-data/blob/main/json/licenses.json
https://github.com/spdx/license-list-data/blob/main/json/exceptions.json

which can be easily processed using `jq`.

--
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: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Brian Inglis via Cygwin-apps]

On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:

Jon Turney via Cygwin-apps wrote:
PS: I have a local script which checks SPDX Identifiers and expressions. Any 
interest to add this to cygport and then check LICENSE settings?

Oh, yes please. That sounds like a good idea.



Attached.
The new script uses the SPDX webpages to create the license file. I didn't find 
a usable single license list at https://github.com/spdx


What about:

https://spdx.github.io/license-list-data/

and everything under:

https://github.com/spdx/license-list-data

The data/spdx-licenses file is not included in the patch. It could be generated 
from the source dir with:

$ tools/spdx-check -f data/spdx-licenses -m
...
data/spdx-licenses: created
$ sha1sum data/spdx-licenses
80a19d6891d08bf34113464464ee12308374c792 *data/spdx-licenses
The changes to the meson files are guessed. I didn't test the meson build yet.


--
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

[ITA] bash-completion/-devel

[Brian Inglis via Cygwin-apps]

I would like to co-maintain or adopt and revive the above package, which was 
adopted by Eric but not updated since Yaakov.


Below are links to existing source packages, build repos, scallywag runs, and 
updated package info.


I would like to further improve the sdesc and ldesc provided to reflect that 
completions are provided for thousands of commands and their options and arguments.



Bash Completions and development

Existing source package:

https://cygwin.com/packages/summary/bash-completion-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=bash-completion

Bash Completions and development

bash-completion is a collection of shell functions that use the
programmable completion feature of bash.

For more information see the project home page:

https://github.com/scop/bash-completion

See below for details of changes:

https://github.com/scop/bash-completion/blob/master/CHANGELOG.md


bash-completion Bash Completions

Existing package:

https://cygwin.com/packages/summary/bash-completion.html


bash-completion-devel   Bash Completions (development)

Existing package:

https://cygwin.com/packages/summary/bash-completion-devel.html

Re: Let's Encrypt Dropping Cross-Signed Root and Intermediates; Issuing New Intermediates; New Cert Chains

[Brian Inglis via Cygwin-apps]

Unsure of impact and action required was why I posted - Cygwin, Sourceware, GNU, 
Kernel.org, etc. use LE certs.


Looks like new root and/or intermediate certs are available to be packaged 
before they will be used 2024 June 6 and old cross-signed root if included may 
be removed before 2024 Sep 30.


Seems that outdated Android versions will no longer work as before on LE 
certified sites, but probably others have also changed by now.


On 2024-04-19 06:48, Jon Turney via Cygwin-apps wrote:

On 17/04/2024 04:48, Brian Inglis via Cygwin-apps wrote:
Is this FYI, or are you suggesting there is some specific action we need to 
take?


https://letsencrypt.org/2023/07/10/cross-sign-expiration
Shortening the Let's Encrypt Chain of Trust
"On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in 
requests made to our /acme/certificate API endpoint.
On Thursday, June 6th, 2024, we will stop providing the longer cross-signed 
chain entirely.

On Monday, September 30th, 2024, the cross-signed certificate will expire."

https://letsencrypt.org/2024/03/19/new-intermediate-certificates
New Intermediate Certificates
"Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new 
Intermediate CA Certificates containing the new public keys."


https://letsencrypt.org/2024/04/12/changes-to-issuance-chains
Deploying Let's Encrypt's New Issuance Chains
"On Thursday, June 6th, 2024, we will be switching issuance to use our new 
intermediate certificates. Simultaneously, we are removing the DST Root CA X3 
cross-sign from our API, aligning with our strategy to shorten the Let’s 
Encrypt chain of trust. We will begin issuing ECDSA end-entity certificates 
from a default chain that just contains a single ECDSA intermediate, removing 
a second intermediate and the option to issue an ECDSA end-entity certificate 
from an RSA intermediate."


--
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: calm: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate

[Brian Inglis via Cygwin-apps]

On 2024-04-17 13:37, Jon Turney via Cygwin-apps wrote:

On 17/04/2024 15:17, Brian Inglis via Cygwin-apps wrote:

On 2024-04-17 07:08, cygwin-no-reply wrote:
ERROR: package 'geoipupdate' is at paths geoipupdate and 
GeoIP-database/geoipupdate


This is the "change things to that the geoipupdate package belongs to 
GeoIP-database source" I previously mentioned.


I've done that, and the upload seems to have succeeded.

I also fixed a typo I noticed in the geoipupdate DESCRIPTION:

- THe geoipupdate database updater script downloads the latest available
+ The geoipupdate database updater script downloads the latest available


Thanks Jon,

I also noticed that offline, committed, merged to master, and pushed.

--
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: [ITA] GeoIP, GeoIP-database, geoipupdate

[Brian Inglis via Cygwin-apps]

On 2024-04-17 13:38, Jon Turney via Cygwin-apps wrote:

On 17/04/2024 00:39, Brian Inglis via Cygwin-apps wrote:

On 2024-04-16 13:31, Jon Turney via Cygwin-apps wrote:

On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last 
("unofficial") version of the legacy code committed noted in the ChangeLog 
as 1.7.0, and a new upstream source for legacy format free databases 
converted when the official current upstream databases are updated.


My very limited, vague understanding was that GeoIP is obsolete and users 
should move to something newer? What packages do we have that actually depend 
on this? Are there other ways to update them?


$ cygcheck-dep -nqS libGeoIP1 libmaxminddb0
  libGeoIP1: is needed for ( GeoIP libdns1104 libdns1105 libdns166 libdns169 
libGeoIP-devel )
  libmaxminddb0: is needed for ( bind libdns1106 libmaxminddb-devel 
lighttpd-mod_maxminddb )


Looks like older bind used free legacy GeoIP databases, "current" bind uses 
current library and current GeoIP2 databases which require free registration 
to get an API key with limits.
The new upstream source for free legacy GeoIP databases converts upstream 
GeoIP2 databases and makes them available under its CC-by-4.0 licence.


The most recent bind package was built with '--without-geoip'.  Does this need 
to change back again?


It was built with libmaxminddb which requires the Maxmind API key registration 
to download the free but not publicly available GeoLite2 and new geoipupdate 
which can only download from new databases with the new API and registered key.


https://cygwin.com/packages/summary/libdns1106.html
https://geoip.site/ [another legacy alternative]
https://dev.maxmind.com/geoip/geolite2-free-geolocation-data

This supports bind geoDNS applications like geo-[b]locking and geo-redirection.

$ cpm-sum libdns1{6{6,9},10{4,5,6}} | grep 
'dns\|bind\|maxmind\|GeoIP\|depends:\|ackage:$'

Package: libdns166
    depends:
    cygwin, libGeoIP1, libgssapi_krb5_2, libisc160, libjson-c2, libkrb5_3,
    rdepends:
    dnsperf, libbind9_160, libirs160, libisccfg160
    source package:
    bind


I guess there's another thread to pull on here.

The code which looks for "old soversions we don't need to keep anymore" isn't 
smart enough currently to realize that it can get rid of all of these old libdns 
soversions.


Assuming that gets fixed (...), do we still have users?


The main user may still be the GeoIP binary package utilities geoiplookup/6.
I and presumably others use them in scripts to inform where sites and addresses 
are likely geo or net located or distributed; for example:


$ geoiplookup sourceware.org
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, 00, N/A, N/A, N/A, 37.750999, -97.821999, 0, 0
GeoIP ASNum Edition: AS17314 REDHAT-HOSTED
$ geoiplookup redhat.com
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, VA, Virginia, Ashburn, 20149, 39.046902, 
-77.490303, 511, 0

GeoIP ASNum Edition: AS14618 AMAZON-AES
$ geoiplookup ibm.com
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, WA, Washington, Seattle, 98160, 47.603401, 
-122.341400, 819, 0

GeoIP ASNum Edition: AS16625 AKAMAI-AS
$ geoiplookup geoip.site
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, 00, N/A, N/A, N/A, 37.750999, -97.821999, 0, 0
GeoIP ASNum Edition: AS13335 CLOUDFLARENET
$ geoiplookup6 dronecode.org.uk
GeoIP Country V6 Edition: GB, United Kingdom
GeoIP ASNum V6 Edition: AS44684 Mythic Beasts Ltd
GeoIP City Edition V6, Rev 1: GB, 00, N/A, N/A, 51.496399, -0.122400, 0, 0
$ geoiplookup mythic-beasts.com
GeoIP Country Edition: GB, United Kingdom
GeoIP City Edition, Rev 1: GB, 00, N/A, N/A, N/A, 51.496399, -0.122400, 0, 0
GeoIP ASNum Edition: AS44684 Mythic Beasts Ltd

These show that sourceware, RedHat, IBM, and geoip.site all use CDNs; geoip.site 
and dronecode (and RPi), are all hosted by Mythic Beasts, and their geoloc 
places them in the Docklands at Millwall near two of their colos!


The accuracy radius (2nd last #) in km follows lat, long, but from often within 
.01 of that value, e.g. 511 => ~5 actual ~3.3km from AWS US-East-1; 819 => ~8 
actual ~2km from Seattle Colo with Equinix, Shaw(/Rogers), other colos, and 
another ~600m from H5, and 1-15km from Cisco, Cyxtera, other SEA1.


These legacy files converted from Maxmind GeoLite2 sources appear to be somewhat 
better than the previous Maxmind legacy GeoLite and CSV sources.


--
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: calm: ERROR: Upload failed: cd: Access failed: No such file (/x86_64/release)

[Brian Inglis via Cygwin-apps]

On 2024-04-17 14:15, Jon Turney via Cygwin-apps wrote:

On 17/04/2024 20:26, Brian Inglis via Cygwin-apps wrote:

Fairly straightforward upgrade of packages.
Is anything demented about my setup:

$ cygport GeoIP.cygport upload
 >>> Uploading GeoIP-1.7.0-1.x86_64
 >>> Running lftp sftp://cygwin:@cygwin.com
cd: Access failed: No such file (/x86_64/release)
*** ERROR: Upload failed


Thanks for reporting this.

When I connect using `lftp sftp://cygwin` I now seem to be logged in to the 
sftp *root* instead of /home/Brian\ Inglis!


But in future, if you are ever reporting "I think I have access to stuff on 
sourceware I shouldn't have access to", you may, exceptionally in that situation 
only, send me a private mail.


Thanks Jon,

Never occurred to me it was a security glitch, nor even to look around except in 
my own home dir, but I will try to remember to think that way, and let you or 
someone know quietly in future.
Did sysadmin work long enough to have little interest now, except when unable to 
do something admin would allow, and have to ask someone ;^>


Or is this just a way to allow my GeoIP... updates to be fixed up before I can 
do anything more?


This was the result of a sshd configuration error which has been rectified by 
sourceware overseers.


Oops!
Glad I noticed and mentioned that, rather than just wait and see if it was 
rectified: don't want to be (much of) a pain, but you never know, as here.


--
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

calm: ERROR: Upload failed: cd: Access failed: No such file (/x86_64/release)

[Brian Inglis via Cygwin-apps]

Hi folks,

Fairly straightforward upgrade of packages.
Is anything demented about my setup:

$ cygport GeoIP.cygport upload
>>> Uploading GeoIP-1.7.0-1.x86_64
>>> Running lftp sftp://cygwin:@cygwin.com
cd: Access failed: No such file (/x86_64/release)
*** ERROR: Upload failed

When I connect using `lftp sftp://cygwin` I now seem to be logged in to the sftp 
*root* instead of /home/Brian\ Inglis!


Or is this just a way to allow my GeoIP... updates to be fixed up before I can 
do anything more?


--
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: calm: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate

[Brian Inglis via Cygwin-apps]

On 2024-04-17 07:08, cygwin-no-re...@cygwin.com wrote:

ERROR: package 'geoipupdate' is at paths geoipupdate and 
GeoIP-database/geoipupdate
ERROR: error while merging uploaded x86_64 packages for Brian Inglis
SUMMARY: 2 ERROR(s)


Hi folks/Jon,

Replacing obsolete compiled geoipupdate package with script subpackage which 
obsoletes the previous geoipupdate-debuginfo.


--
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

Let's Encrypt Dropping Cross-Signed Root and Intermediates; Issuing New Intermediates; New Cert Chains

[Brian Inglis via Cygwin-apps]

Hi folks,

https://letsencrypt.org/2023/07/10/cross-sign-expiration
Shortening the Let's Encrypt Chain of Trust
"On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in 
requests made to our /acme/certificate API endpoint.
On Thursday, June 6th, 2024, we will stop providing the longer cross-signed 
chain entirely.

On Monday, September 30th, 2024, the cross-signed certificate will expire."

https://letsencrypt.org/2024/03/19/new-intermediate-certificates
New Intermediate Certificates
"Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new 
Intermediate CA Certificates containing the new public keys."


https://letsencrypt.org/2024/04/12/changes-to-issuance-chains
Deploying Let's Encrypt's New Issuance Chains
"On Thursday, June 6th, 2024, we will be switching issuance to use our new 
intermediate certificates. Simultaneously, we are removing the DST Root CA X3 
cross-sign from our API, aligning with our strategy to shorten the Let’s Encrypt 
chain of trust. We will begin issuing ECDSA end-entity certificates from a 
default chain that just contains a single ECDSA intermediate, removing a second 
intermediate and the option to issue an ECDSA end-entity certificate from an RSA 
intermediate."


--
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: [ITA] GeoIP, GeoIP-database, geoipupdate

[Brian Inglis via Cygwin-apps]

On 2024-04-16 13:31, Jon Turney via Cygwin-apps wrote:

On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last 
("unofficial") version of the legacy code committed noted in the ChangeLog as 
1.7.0, and a new upstream source for legacy format free databases converted 
when the official current upstream databases are updated.


My very limited, vague understanding was that GeoIP is obsolete and users should 
move to something newer? What packages do we have that actually depend on this? 
Are there other ways to update them?


$ cygcheck-dep -nqS libGeoIP1 libmaxminddb0
 libGeoIP1: is needed for ( GeoIP libdns1104 libdns1105 libdns166 libdns169 
libGeoIP-devel )
 libmaxminddb0: is needed for ( bind libdns1106 libmaxminddb-devel 
lighttpd-mod_maxminddb )


Looks like older bind used free legacy GeoIP databases, "current" bind uses 
current library and current GeoIP2 databases which require free registration to 
get an API key with limits.
The new upstream source for free legacy GeoIP databases converts upstream GeoIP2 
databases and makes them available under its CC-by-4.0 licence.


$ cpm-sum libdns1{6{6,9},10{4,5,6}} | grep 
'dns\|bind\|maxmind\|GeoIP\|depends:\|ackage:$'

Package: libdns166
   depends:
   cygwin, libGeoIP1, libgssapi_krb5_2, libisc160, libjson-c2, libkrb5_3,
   rdepends:
   dnsperf, libbind9_160, libirs160, libisccfg160
   source package:
   bind
Package: libdns169
   depends:
   cygwin, libGeoIP1, libgssapi_krb5_2, libisc166, libjson-c2, libkrb5_3,
   rdepends:
   dnsperf, libbind9_160, libirs160, libisccfg160
   source package:
   bind
Package: libdns1104
   depends:
   cygwin, libGeoIP1, libgssapi_krb5_2, libisc1100, libjson-c2, libkrb5_3,
   rdepends:
   bind, bind-utils, libbind9-devel, libbind9_161, libirs161, libisccfg163
   source package:
   bind
Package: libdns1105
   depends:
   cygwin, libGeoIP1, libgssapi_krb5_2, libisc1100, libjson-c2, libkrb5_3,
   rdepends:
   bind, bind-utils, libbind9-devel, libbind9_161, libirs161, libisccfg163
   source package:
   bind
Package: libdns1106
   depends:
   libmaxminddb0, libssl1.1, libxml2
   rdepends:
   bind, bind-utils, dnsperf, libbind9-devel, libbind9_161, libirs161,
   source package:
   bind


Is there any easy way of overridding package version from
ac_init_version without patching configure.ac?


Generally, no.


Tried the obvious stuff with no effect, so applied patch.

As part of this upgrade, the geoipupdate source and databases are no longer 
available, so the new upstream database source update script becomes a new 
database subpackage and script geoipupdate, and the old geoipupdate source, 
binary, and debuginfo packages should become obsolete.


Is there anything special required to replace a source package and binaries 
with a binary subpackage?


Uh... I had to reread that several times (and compare with the cygport) before 
it this question made sense.


So: when you come to upload, I'll need to change things to that the geoipupdate 
package belongs to GeoIP-database source.


geoipupdate should probably obsolete geoipupdate-debuginfo, if it's now empty.


Good point, thanks.


Reviewing the cygports, everything looks OK.

I'd make the comment that the text about scheduling geoipupdate to run should be 
in geoipupdate_DESCRIPTION, rather than in GeopIP-database's description.


Good point, I will rework some info.


I added GeoIP and GeoIP-database to your packages.


Cheers, thanks!

--
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: package update announcements not being accepted or forwarded?

[Brian Inglis via Cygwin-apps]

On 2024-04-14 21:16, gs-cygwin@gluelogic.com wrote:

On Sun, Apr 14, 2024 at 04:08:25PM -0600, Brian Inglis via Cygwin-apps wrote:

I sent an announcement for *cpuid* after the fixes, which appears to have
made it into the inbox and archives, but I did not see it and neither has
mail-archive, so resent the announcement.
Has anyone else received that announcement for *cpuid* on the list?


FYI: I *have not* seen it, though I did get this message from you.


Thanks Glenn,

I think my mistake was resending with the same date and message id, which inbox 
uses as a key, and archives seems to have interpreted as a follow-up to mosh 
announcement? Trying a resend with updated date and message-id!


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

package update announcements not being accepted or forwarded?

[Brian Inglis via Cygwin-apps]

Hi folks,

I sent an announcement for *cpuid* after the fixes, which appears to have made 
it into the inbox and archives, but I did not see it and neither has 
mail-archive, so resent the announcement.

Has anyone else received that announcement for *cpuid* on the list?

--
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: package uploads not being processed again - calm failed or stuck?

[Brian Inglis via Cygwin-apps]

On 2024-04-14 15:10, Jon Turney via Cygwin-apps wrote:

On 14/04/2024 22:01, Brian Inglis via Cygwin-apps wrote:

On 2024-04-14 13:53, Brian Inglis via Cygwin-apps wrote:
Not seeing any progress hours after package upload - master setup.ini not 
updated and no calm emails received - has calm failed or is it stuck?


`ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ 
command to show us what calm is doing!


Sorry, this isn't going to happen for various reasons.


Achim - none of your announced releases appear to have been processed yet!


Thanks to whoever got the process going again a half hour ago!
I could see from curl -I the setup.ini last-modified date updated.


No problem.  sourceware overseers have re-arranged things so it won't be 
automatically killed by systemd for lols, and I am assured it should carry on 
running now...


Some emails reporting uploads that had been processed have been lost during the 
confusion.


We apologize for the inconvenience.


Thanks Jon,

No need for apologies from you - overseers should have systemd email apologies 
to the appropriate mailing list(s) when daemon services have to be restarted 
after systemd has decided they no longer need to be running ;^>


--
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: package uploads not being processed again - calm failed or stuck?

[Brian Inglis via Cygwin-apps]

On 2024-04-14 13:53, Brian Inglis via Cygwin-apps wrote:
Not seeing any progress hours after package upload - master setup.ini not 
updated and no calm emails received - has calm failed or is it stuck?


`ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ 
command to show us what calm is doing!


Achim - none of your announced releases appear to have been processed yet!


Thanks to whoever got the process going again a half hour ago!
I could see from curl -I the setup.ini last-modified date updated.

--
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

package uploads not being processed again - calm failed or stuck?

[Brian Inglis via Cygwin-apps]

Not seeing any progress hours after package upload - master setup.ini not 
updated and no calm emails received - has calm failed or is it stuck?


`ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ 
command to show us what calm is doing!


Achim - none of your announced releases appear to have been processed yet!

--
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: package uploads not being processed - calm failed or stuck?

[Brian Inglis via Cygwin-apps]

On 2024-04-13 14:34, Jon Turney via Cygwin-apps wrote:

On 13/04/2024 21:12, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Not seeing any progress hours after package upload - master setup.ini not 
updated and no calm emails received - has calm failed or is it stuck?


Thanks for the report.

Not sure what went wrong there, but I've restarted it and it seems to have 
processed all the pending uploads.


Thanks Jon,

Hopefully there is something in some log that can help you figure out the cause.

--
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: package uploads not being processed - calm failed or stuck?

[Brian Inglis via Cygwin-apps]

On 2024-04-13 14:12, Brian Inglis via Cygwin-apps wrote:
Not seeing any progress hours after package upload - master setup.ini not 
updated and no calm emails received - has calm failed or is it stuck?


`ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ 
command to show us what calm is doing?


--
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

package uploads not being processed - calm failed or stuck?

[Brian Inglis via Cygwin-apps]

Hi folks,

Not seeing any progress hours after package upload - master setup.ini not 
updated and no calm emails received - has calm failed or is it stuck?


--
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

[ITA] GeoIP, GeoIP-database, geoipupdate

[Brian Inglis via Cygwin-apps]

I would like to adopt and revive the above packages with the last ("unofficial") 
version of the legacy code committed noted in the ChangeLog as 1.7.0, and a new 
upstream source for legacy format free databases converted when the official 
current upstream databases are updated.


Is there any easy way of overridding package version from
ac_init_version without patching configure.ac?

As part of this upgrade, the geoipupdate source and databases are no longer 
available, so the new upstream database source update script becomes a new 
database subpackage and script geoipupdate, and the old geoipupdate source, 
binary, and debuginfo packages should become obsolete.


Is there anything special required to replace a source package and binaries with 
a binary subpackage?


Below are links to existing source packages, build repos, scallywag runs, and 
updated package info.



Geographic IP Lookup utilities, development, and runtime

Existing source package:

https://cygwin.com/packages/summary/GeoIP-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/GeoIP/tree/GeoIP.cygport?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP

Geographic IP Lookup utilities, development, and runtime

GeoIP finds geographic and network locations of an IP address.

For more information see the project home page:

https://github.com/maxmind/geoip-api-c

See below for details of changes:

https://github.com/maxmind/geoip-api-c/blob/master/ChangeLog


GeoIP-database  Geographic IP Lookup (databases)

Existing source package:

https://cygwin.com/packages/summary/GeoIP-database-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/GeoIP-database/tree/?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP-database

GeoIP-database  Geographic IP Lookup (databases)

GeoIP finds geographic and network locations of an IP address.
These databases are extracts of free GeoLite2 data from Maxmind 
https://www.maxmind.com/ and are less accurate than the commercial databases.


geoipupdate Geographic IP Lookup (database update utility)

geoipupdate database updater script downloads the latest available data
and updates the installed files.
The script may be run manually, from a login profile script, as a cron
job, or from an MS Windows Scheduled Task.

For more information see the project home page:

https://mailfud.org/geoip-legacy

This package will rarely be updated as the data changes weekly and the
database updater script geoipupdate will keep the data current.


Existing source package:

https://cygwin.com/packages/summary/geoipupdate-src.html

Existing cygport:

https://cygwin.com/cgit/cygwin-packages/geoipupdate/

[ITA] GeoIP, GeoIP-database, geoipupdate

[Brian Inglis via Cygwin-apps]

-- 
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
patching configure.ac?

In this update, the geoipupdate source and databases are no longer
available, so the new upstream database source update script becomes a
new database subpackage and script geoipupdate, and the old geoipupdate
source, binary, and debuginfo packages should become obsolete.

Is there anything special required to replace a source package and
binaries with a binary subpackage?

Below are links to existing source packages, build repos, scallywag
runs, and updated package info.


Geographic IP Lookup utilities, development, and runtime

Existing source package:

https://cygwin.com/packages/summary/GeoIP-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/GeoIP/tree/GeoIP.cygport?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP

Geographic IP Lookup utilities, development, and runtime

GeoIP finds geographic and network locations of an IP address.

For more information see the project home page:

https://github.com/maxmind/geoip-api-c

See below for details of changes:

https://github.com/maxmind/geoip-api-c/blob/master/ChangeLog


GeoIP-database  Geographic IP Lookup (databases)

Existing source package:

https://cygwin.com/packages/summary/GeoIP-database-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/GeoIP-database/tree/?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP-database

GeoIP-database  Geographic IP Lookup (databases)

GeoIP finds geographic and network locations of an IP address.
These databases are extracts of free GeoLite2 data from Maxmind 
https://www.maxmind.com/ and are less accurate than the commercial databases.

geoipupdate Geographic IP Lookup (database update utility)

geoipupdate database updater script downloads the latest available data
and updates the installed files.
The script may be run manually, from a login profile script, as a cron
job, or from an MS Windows Scheduled Task.

For more information see the project home page:

https://mailfud.org/geoip-legacy

This package will rarely be updated as the data changes weekly and the
database updater script geoipupdate will keep the data current.


Existing source package:

https://cygwin.com/packages/summary/geoipupdate-src.html

Existing cygport:

https://cygwin.com/cgit/cygwin-packages/geoipupdate/

OSS-Sec: X.Org Security Advisory

[Brian Inglis via Cygwin-apps]

Issues in X.Org X server prior to 21.1.12 etc.
https://seclists.org/oss-sec/2024/q2/22

--
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: xz upstream backdoor compromise (was: Cygwin: Linux xz issue)

[Brian Inglis via Cygwin-apps]

On 2024-03-29 16:43, Ron Murray via Cygwin wrote:
There is a serious security issue with xz (and liblzma) versions 5.6.0-1 and 
5.6.1-1. I note that cywin currently is suggesting an upgrade to 5.6.1-1, which 
is unsafe. I've looked at the cygwin archives and I don't see a reference to 
this: sorry if you're already aware of this issue.


References:
https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
https://access.redhat.com/security/cve/CVE-2024-3094
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-backdoor-in-xz-utils/


https://seclists.org/oss-sec/2024/q1/268

--
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: [PATCH setup] Fix Chinese Help Message fall in dead loop .

[Brian Inglis via Cygwin-apps]

On 2024-03-28 19:40, 赵伟 via Cygwin-apps wrote:

---
  libgetopt++/include/getopt++/DefaultFormatter.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libgetopt++/include/getopt++/DefaultFormatter.h 
b/libgetopt++/include/getopt++/DefaultFormatter.h
index ee2397f5..43c253a5 100644
--- a/libgetopt++/include/getopt++/DefaultFormatter.h
+++ b/libgetopt++/include/getopt++/DefaultFormatter.h
@@ -64,6 +64,7 @@ class DefaultFormatter {
 {
   // TODO: consider using a line breaking strategy here.
   int pos = helpmsg.substr(0,h_len).find_last_of(" ");
+ if(!pos)break; /*In Chinese Helpmsg,may has no space,so pos ==0,and 
code will fall in dead loop here*/
   theStream << helpmsg.substr(0,pos)
 << std::endl << std::string (o_len, ' ');
   helpmsg.erase (0,pos+1);


It seems that the best approach for Chinese translations would be to:

- add spaces at sentence or word breaks in translations before 35 or 45 bytes, 
if that is the length unit, worth of characters are output in each column; or


- add a language dependent line breaking strategy, to honour characters not to 
be placed at the beginning or ends of lines or split; or


- split between characters, as with long strings in other languages.

--
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: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Brian Inglis via Cygwin-apps]

On 2024-03-28 11:49, Jon Turney via Cygwin-apps wrote:

On 27/03/2024 21:18, Brian Inglis via Cygwin-apps wrote:

On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:

On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

[...]


Are they supposed to migrate to some alternate bindings maybe available from 
a separate repo? Or are they just out of luck?


SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.


Nice :S

Feel free to purge as appropriate, or tell me what to add to cygport, hints, 
etc!


So, the long list of source versions will hopefully be reduced in the 
fullness of time...


Could I just add to nghttp2.cygport that nghttp2 obsoletes 
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2 
vx.x.x around?


You could, but that's probably not the correct thing to do unless you really, 
really want to forcibly uninstall those packages for anyone who has installed 
them, which seems like unnecessary breakage.


I don't think you have to do anything.  There's nothing "wrong" here.

If it really offends your sense of aesthetics, I suggest you just expire some 
subset of the old versions using the vault command [1].


[1] https://cygwin.com/package-upload.html#deleting


Great idea!

Current setup packages are:

python3-nghttp2  1.43.0-1 x86_64
python36-nghttp2 1.46.0-1 x86_64
python37-nghttp2 1.46.0-1 x86_64
python38-nghttp2 1.51.0-1 x86_64
python39-nghttp2 1.51.0-1 x86_64

and 37 obsoletes 36 obsoletes 3, so from src:

Version  Package Size   DateFiles  Status
   1.31.0-1 (source) 1512 KiB 2018-03-16 01:07 [list of files] stable
   1.37.0-1 (source) 1593 KiB 2019-03-27 03:17 [list of files] stable
   1.43.0-1 (source) 3885 KiB 2021-05-30 06:33 [list of files] stable
   1.44.0-1 (source) 3884 KiB 2021-07-19 11:32 [list of files] stable
   1.45.1-1 (source) 3929 KiB 2021-09-26 12:08 [list of files] stable
   1.46.0-1 (source) 3936 KiB 2021-10-24 03:17 [list of files] stable
   1.49.0-1 (source) 4021 KiB 2022-08-28 01:08 [list of files] stable
   1.50.0-1 (source) 4019 KiB 2022-09-25 19:43 [list of files] stable
   1.51.0-1 (source) 4025 KiB 2022-11-13 20:42 [list of files] stable
   1.58.0-1 (source) 1515 KiB 2023-10-29 17:13 [list of files] stable
   1.59.0-1 (source) 1516 KiB 2024-01-21 19:31 [list of files] stable
   1.60.0-1 (source) 1554 KiB 2024-03-03 17:16 [list of files] stable

I should be able to vault 1.31-1.45 and 1.49-1.50, or should I also add 1.46?

Could I also selectively upload -*.tar.xz for old python package versions?

--
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: [tz] Ubuntu drops old-style links - tzdata split test package

[Brian Inglis via Cygwin-apps]

On 2024-03-28 04:13, Corinna Vinschen via Cygwin-apps wrote:

On Mar 28 02:25, Brian Inglis via Cygwin-apps wrote:

I have released and announced a test package of tzdata 2024a-2 split into
three install packages: base tzdata, optional tzdata-right, and redundant
tzdata-posix, each containing all the legacy zones so that tzset continues
to work as before.

I could not reduce the base installed zones by many, because most were used
by tzset, but I did drop a couple of large zone source files, produced by
the build, that were previously included to allow users to see the source
zones, rules, and links in effect, saving ~1MB, and dropping the overall
default base installed file sizes by ~80% to ~20% of current, and download
tar size by ~60% to ~40%; for all zones aggregate total installed file sizes
are dropped by ~35% to ~65%, and download tar sizes by ~30% to ~70% of
current:

install   tar   tzdata
  721KB  172KB   base
  984KB   78KB   right
  669KB   74KB   posix
 1367KB  444KB   source
 3667KB  452KB   current

Please check out the announcement, cygwin list echo, source and install
package summary web pages, cygport changes, setup entries, scallywag builds,
and let me know if there is anything you see that could benefit from
improvement.


Fedora Rawhide is not following this scheme.  For F40 and F41 it still
prepares single tzdata packages.  FWIW, OpenSuSE also only comes with a
single timezone package in Tumbleweed.

Comparing the Cygwin and the Fedora package, the only differences are:

  Cygwin comes with two files not in the Fedora package:

/usr/share/zoneinfo/rearguard.zi


Source tzdata zones, rules, links,
- driven by tzdata make symbol settings,
- in legacy tzdata format supported by newlib-cygwin libc,
- generated as base zic input source to provide all the legacy zones used by 
tzset, and
- allows users to view the tzdata rules in effect for their zone(s) of interest; 
- dropped in the test package,
- along with tzdata.zi, which is the abbreviated generated source file used by 
zic to build the zoneinfo subtrees,

- driven also by zic parameters for each subtree, almost identical to Fedora:

https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec

- except they still use the deprecated obsolete yearistype shell script with 
zic, supporting deprecated obsolete US presidential and odd/even year rules.


Once we know that the libc code is updated to support the new zic output data 
ranges, we could transition to main or vanguard source formats and slim output 
formats, as long as the required tzset zone files are still generated in those 
formats.


This is the same as provided in RHEL, see notes on tzdata-2018e in:

https://access.redhat.com/articles/1187353

and Fedora

https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec


/usr/share/zoneinfo/zonenow.tab


Compare the RH notes, Fedora tzdata.spec embedded changelog, cygport git log, 
and cygwin-announce upstream release notes, for similar information.


New minimal tzdata zone selection which builds *only* the minimal zones required 
to provide current time around the world, but may require selection of a 
different zone; supported by make and in /bin/tzselect by undocumented -t 
zonetabtype option.



  Fedora comes with two files not in the Cygwin package:

/usr/share/zoneinfo/leap-seconds.list


IERS/NIST upstream NTP leap-seconds.list PD distribution file: we provide only 
the tzdata format leapseconds file in /usr/share/zoneinfo/, generated from the 
NTP list, instead; that way we do not need to specify another licence, which 
appears not to be stated in:


https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec


/usr/share/zoneinfo/posixrules


Deprecated obsolete legacy rules: see tzdata-2020b notes discussing patch to 
provide this in:


https://access.redhat.com/articles/1187353

and 2020d-3 notes in:

https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec


That's all.  And given that space is not one of the major limiting
factors anymore...

   cyg$ du -sh /usr/share/zoneinfo
   6.6M/usr/share/zoneinfo

   fed$ du -sh /usr/share/zoneinfo
   4.6M /usr/share/zoneinfo

...I do wonder a bit if this split is really necessary after all.


It cuts the base install (--apparent) size by ~3MB to 721KB, time and load for 
this by a factor of 5, for mirrors, CI, and other repetitive container and 
packaged build server installs like ansible, docker, scallywag, etc.


Few users are likely to use any of the right or redundant posix subtrees, unless 
they have astrophysics or time/frequency physics interests.


Astronomers and astrologers, CLDR, ICU, and Cygwin Windows tzmap are better 
served by providing all the legacy zones.


FYI:

The primary maintainer of tzcode/tzdata is an Ubuntu user, and keen to drop as 
much of the legacy and what he considers as questionable history as possible, 
despite a project data fork

Re: [tz] Ubuntu drops old-style links - tzdata split test package

[Brian Inglis via Cygwin-apps]

On 2024-03-23 15:11, Corinna Vinschen via Cygwin-apps wrote:

On Mar 23 10:38, Brian Inglis via Cygwin-apps wrote:

It looks to me that tzset.c prioritizes the Windows label over the country,
and it may be a better match prioritizing the country over the label, if the
country is not 001/"", nor ZZ, which are the generic entries.


The Windows timezone is the relevant setting in the first place becasue
that's what indicvates the actual local time *as the user chose*.
The territory should only be a secondary hint to choose the right
POSIX entry.

For instance, I know people always using UTC, independently of their
territory setting. If the territory rules, this user choice would be
broken in Cygwin.


It also is not clear what tzset should do when tzmap has a list of zones to
choose from, for example:

   { L"Mountain Standard Time", L"CA", L"America/Edmonton
America/Cambridge_Bay America/Inuvik" },
   { L"Mountain Standard Time", L"US", L"America/Denver America/Boise" },
   { L"US Mountain Standard Time", L"CA", L"America/Creston
America/Dawson_Creek America/Fort_Nelson" },

it currently just prints the first, but perhaps it should print all relevant
entries and the caller should handle the alternatives?


tzset is called from the shell default profile.  It has to use exactly
one, valid entry, so time works as desired without forcing interactivity.

If the user doesn't like it, the user can always override tzset's choice
in her own profile.


I have released and announced a test package of tzdata 2024a-2 split into three 
install packages: base tzdata, optional tzdata-right, and redundant 
tzdata-posix, each containing all the legacy zones so that tzset continues to 
work as before.


I could not reduce the base installed zones by many, because most were used by 
tzset, but I did drop a couple of large zone source files, produced by the 
build, that were previously included to allow users to see the source zones, 
rules, and links in effect, saving ~1MB, and dropping the overall default base 
installed file sizes by ~80% to ~20% of current, and download tar size by ~60% 
to ~40%; for all zones aggregate total installed file sizes are dropped by ~35% 
to ~65%, and download tar sizes by ~30% to ~70% of current:


install   tar   tzdata
 721KB  172KB   base
 984KB   78KB   right
 669KB   74KB   posix
1367KB  444KB   source
3667KB  452KB   current

Please check out the announcement, cygwin list echo, source and install package 
summary web pages, cygport changes, setup entries, scallywag builds, and let me 
know if there is anything you see that could benefit from improvement.


--
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: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Brian Inglis via Cygwin-apps]

On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:

On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:


[...]


Not sure why my source package nghttp2 shows python install packages, when 
they were dropped after 1.43 IIRC: build deps no longer include python/-devel?


If you haven't taken any specific action to retire the python-3x-nghttp2 
packages, the existing ones will continue to be available indefinitely.


Firstly, it seems there's a question here about what are upstream's plans for 
the users of the python bindings for this library.


Are they supposed to migrate to some alternate bindings maybe available from a 
separate repo? Or are they just out of luck?


SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.

And why does that nghttp2 source package show a dozen archived source 
versions, when its installed packages have only three?


The simple answer to that is we retain the source package for all available 
install packages.  This seems essential for an open-source project.


Now, as to why there are so many installable packages, this is the intersection 
of a couple of unfortunate issues.


1. 'python3-nghttp2' is an "old-style" obsoletion package, where the package 
exists, but is of category _obsolete, and requires the replacement package.


These are terrible, because we can't remove the obsolete package because that's 
what records the fact of obsoletion.


I actually have some code for calm to internally convert that to a "new-style" 
obsoletion, where the replacement package itself records the obsoletion (i.e. 
python36-nghttp2 obsoletes: python3-nghttp2), which it continues to remember 
about even after the package which contains that obsoleting is expired.


Once that's done, all those "old-style" obsoletion packages lingering in our 
package repository can be removed (along with their corresponding source).


But I still need to do some testing before that can be deployed.

(However, all that's probably not what's actually wanted with python packages: 
it's preferable to have python3-foo be a virtual package which pulls in 
python3x-foo, where python3x is the current python, so that scripted installs 
can be written which ask for python3 and python3-foo and continue to work while 
x changes...)


2. We haven't purged old python versions for a long time, so e.g the python36 
binding packages are still lingering.


As you can see, I'm just now getting around to looking at expiring python36, 
which eventually should lead to python36-nghttp2 being expired (insert some 
observations about how it doesn't have to be me doing these things here)...



Feel free to purge as appropriate, or tell me what to add to cygport, hints, 
etc!


So, the long list of source versions will hopefully be reduced in the fullness 
of time...


Could I just add to nghttp2.cygport that nghttp2 obsoletes 
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2 vx.x.x 
around?


--
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: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Brian Inglis via Cygwin-apps]

On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 
(EOL Dec 2021)?


(I'm still dealing with cleaning up the final pieces of python27 detritus, 
but these should hopefully be much smaller tasks)




nothing should depend from 3.5
not sure for 3.6


I've automated some of the analysis I was doing for python2 packages and the 
results are now available at [1].


So yeah, it looks like nothing uses 3.5.

There are just a couple of packages using 3.6, I guess I'll ping the maintainers 
about those.


[1] https://cygwin.com/packages/reports/python_rebuilds.html


Not sure why my source package nghttp2 shows python install packages, when they 
were dropped after 1.43 IIRC: build deps no longer include python/-devel?


And why does that nghttp2 source package show a dozen archived source versions, 
when its installed packages have only three?


Feel free to purge as appropriate, or tell me what to add to cygport, hints, 
etc!

--
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: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-23 10:38, Brian Inglis via Cygwin-apps wrote:

On 2024-03-23 03:54, Corinna Vinschen via Cygwin-apps wrote:

On Mar 22 10:02, Brian Inglis via Cygwin-apps wrote:

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

We're generating the conversion from Windows to POSIX timezone via
the conversion table from unicode.org:

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org

Plus a few (7, actually) mappings the Unicode consortium missed in
the list (or maybe they are available in the meantime, needs checking).
This is the minimum list of timezone info we need in the tzdata DB.


I generated tzmap.h and generated differences since the last update cldr ~40.
I also searched in the latest for matches for each field attached as first.

I do not know if they will be of help as I see you have already looked at tzmap.

It looks as if the match might better prioritize country code over Windows 
label.


Which match?  I'm not sure what you're trying to tell me.

Basically, we want to generate a POSIX timezone from the current user's
Windows timezone.  This boils down to four questions:

- Is the creation of tzmap.h from unicode.org via the
   tzmap-from-unicode.org script the right thing to do or not?

- If it's the wrong thing to do, what other source do you propose and do
   you have a script to perform the conversion from this source to a
   valid tzmap.h file?

- Otherwise, is the current tzmap-from-unicode.org right or wrong in
   adding these old extra timezone/territory settings, or is even
   some combination missing?

- If so, would you mind to send a patch to fix tzmap-from-unicode.org
   accordingly?


I have a decent background in tzdata, but little in Windows or CLDR, although at 
least information from the latter can be extracted from GitHub.


It looks to me that tzset.c prioritizes the Windows label over the country, and 
it may be a better match prioritizing the country over the label, if the country 
is not 001/"", nor ZZ, which are the generic entries.


It also is not clear what tzset should do when tzmap has a list of zones to 
choose from, for example:


   { L"Mountain Standard Time", L"CA", L"America/Edmonton America/Cambridge_Bay 
America/Inuvik" },

   { L"Mountain Standard Time", L"US", L"America/Denver America/Boise" },
   { L"US Mountain Standard Time", L"CA", L"America/Creston America/Dawson_Creek 
America/Fort_Nelson" },


it currently just prints the first, but perhaps it should print all relevant 
entries and the caller should handle the alternatives?


There also seem to be issues with CLDR data:

 https://postgrespro.com/list/thread-id/2571399

not to mention the delays in updating Windows and CLDR data:

 2021 Samoa DST change in 2024 March/April Windows updates
https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/interim-guidance-for-samoa-dst-changes-2021/ba-p/4048965

 Intermittent updates from tzdata and Windows
https://github.com/unicode-org/cldr/commits/main/common/supplemental/windowsZones.xml

plus they no longer seem to be updating the tzdata version in that file since 
2021a.


From the point of view of tzdata, given most zones are required in tzmap for 
tzset to use, we can not reduce much there: see tzmap summary attached.


So the only significant reductions we can make by splitting are with the right 
and posix subtrees, perhaps in two or a single extra package: see zi summary.


--
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érytzmap total extra
pri 1  87/ 91  4 zones src zonenow.tab
pri 2 210/221 11 zones src zone1970.tab 
pri 3 101/132 31 zones src backzone 
pri 4  19/113 94 zones src backward 
pri 5  32/ 41  9 zones src files 
total 449/598149 zones 

1.8M/usr/share/zoneinfo/posix
2.4M/usr/share/zoneinfo/right
2.8M/usr/share/zoneinfo/
6.9Mtotal

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-23 03:54, Corinna Vinschen via Cygwin-apps wrote:

On Mar 22 10:02, Brian Inglis via Cygwin-apps wrote:

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

We're generating the conversion from Windows to POSIX timezone via
the conversion table from unicode.org:

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org

Plus a few (7, actually) mappings the Unicode consortium missed in
the list (or maybe they are available in the meantime, needs checking).
This is the minimum list of timezone info we need in the tzdata DB.


I generated tzmap.h and generated differences since the last update cldr ~40.
I also searched in the latest for matches for each field attached as first.

I do not know if they will be of help as I see you have already looked at tzmap.

It looks as if the match might better prioritize country code over Windows 
label.


Which match?  I'm not sure what you're trying to tell me.

Basically, we want to generate a POSIX timezone from the current user's
Windows timezone.  This boils down to four questions:

- Is the creation of tzmap.h from unicode.org via the
   tzmap-from-unicode.org script the right thing to do or not?

- If it's the wrong thing to do, what other source do you propose and do
   you have a script to perform the conversion from this source to a
   valid tzmap.h file?

- Otherwise, is the current tzmap-from-unicode.org right or wrong in
   adding these old extra timezone/territory settings, or is even
   some combination missing?

- If so, would you mind to send a patch to fix tzmap-from-unicode.org
   accordingly?


I have a decent background in tzdata, but little in Windows or CLDR, although at 
least information from the latter can be extracted from GitHub.


It looks to me that tzset.c prioritizes the Windows label over the country, and 
it may be a better match prioritizing the country over the label, if the country 
is not 001/"", nor ZZ, which are the generic entries.


It also is not clear what tzset should do when tzmap has a list of zones to 
choose from, for example:


  { L"Mountain Standard Time", L"CA", L"America/Edmonton America/Cambridge_Bay 
America/Inuvik" },

  { L"Mountain Standard Time", L"US", L"America/Denver America/Boise" },
  { L"US Mountain Standard Time", L"CA", L"America/Creston America/Dawson_Creek 
America/Fort_Nelson" },


it currently just prints the first, but perhaps it should print all relevant 
entries and the caller should handle the alternatives?


There also seem to be issues with CLDR data:

https://postgrespro.com/list/thread-id/2571399

not to mention the delays in updating Windows and CLDR data:

2021 Samoa DST change in 2024 March/April Windows updates
https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/interim-guidance-for-samoa-dst-changes-2021/ba-p/4048965

Intermittent updates from tzdata and Windows
https://github.com/unicode-org/cldr/commits/main/common/supplemental/windowsZones.xml

plus they no longer seem to be updating the tzdata version in that file since 
2021a.


--
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: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-22 10:02, Brian Inglis via Cygwin-apps wrote:

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:

I just learned that Ubuntu Noble (24.04) decided to intentionally
split the tzdata package.  Old-style links such as US/Eastern are no
longer included by default, but are available in the tzdata-legacy
package instead.

Just thought I'd share.  I wonder if other distributions / platforms
/ libraries will follow suit.  What do y'all think?

See:
<https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2058249>
<https://stackoverflow.com/questions/78180695/unrecognized-time-zone>



I've been looking at that to reduce Cygwin CI and embedded build server
setup overhead by limiting base install data to:

- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take
advantage of a wide variety of experience in different environments with
different practices and requirements, before making more definite proposals
on the public list.

Please see the attached log for prioritized subsets of tzdata for consideration:
[...]
What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.


We're generating the conversion from Windows to POSIX timezone via
the conversion table from unicode.org:

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org

Plus a few (7, actually) mappings the Unicode consortium missed in
the list (or maybe they are available in the meantime, needs checking).
This is the minimum list of timezone info we need in the tzdata DB.


I generated tzmap.h and generated differences since the last update cldr ~40.
I also searched in the latest for matches for each field attached as first.

I do not know if they will be of help as I see you have already looked at tzmap.

It looks as if the match might better prioritize country code over Windows 
label.


The attached log shows the 449 time zones required to support the latest tzmap.

Counts of each priority compared to all zones are:

pri 1  87/ 91 zones src zonenow.tab
pri 2 210/221 zones src zone1970.tab
pri 3 101/132 zones src backzone
pri 4  19/113 zones src backward
pri 5  32/ 41 zones src 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éryAfrica/Abidjan  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Algiers  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Cairo1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Casablanca   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Johannesburg 1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Lagos1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Maputo   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Nairobi  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Tripoli  1   zonenow.tab zone1970.tab
africa  zone.tab
America/Adak1   zonenow.tab zone1970.tab
northamericazone.tab
America/Anchorage   1   zonenow.tab zone1970.tab
northamericazone.tab
America/Asuncion1   zonenow.tab zone1970.tab
southamericazone.tab
America/Caracas 1   zonenow.tab zone1970.tab
southamericazone.tab
America/Chicago 1   zonenow.tab 

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-22 10:02, Brian Inglis via Cygwin-apps wrote:

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:

I just learned that Ubuntu Noble (24.04) decided to intentionally
split the tzdata package.  Old-style links such as US/Eastern are no
longer included by default, but are available in the tzdata-legacy
package instead.

Just thought I'd share.  I wonder if other distributions / platforms
/ libraries will follow suit.  What do y'all think?

See:
<https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2058249>
<https://stackoverflow.com/questions/78180695/unrecognized-time-zone>



I've been looking at that to reduce Cygwin CI and embedded build server
setup overhead by limiting base install data to:

- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take
advantage of a wide variety of experience in different environments with
different practices and requirements, before making more definite proposals
on the public list.

Please see the attached log for prioritized subsets of tzdata for consideration:
[...]
What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.


We're generating the conversion from Windows to POSIX timezone via
the conversion table from unicode.org:

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org

Plus a few (7, actually) mappings the Unicode consortium missed in
the list (or maybe they are available in the meantime, needs checking).
This is the minimum list of timezone info we need in the tzdata DB.


I generated tzmap.h and generated differences since the last update cldr ~40.
I also searched in the latest for matches for each field attached as first.

I do not know if they will be of help as I see you have already looked at tzmap.

It looks as if the match might better prioritize country code over Windows 
label.


The attached log shows the 449 time zones required to support the latest tzmap.

--
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
Africa/Abidjan  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Algiers  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Cairo1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Casablanca   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Johannesburg 1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Lagos1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Maputo   1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Nairobi  1   zonenow.tab zone1970.tab
africa  zone.tab
Africa/Tripoli  1   zonenow.tab zone1970.tab
africa  zone.tab
America/Adak1   zonenow.tab zone1970.tab
northamericazone.tab
America/Anchorage   1   zonenow.tab zone1970.tab
northamericazone.tab
America/Asuncion1   zonenow.tab zone1970.tab
southamericazone.tab
America/Caracas 1   zonenow.tab zone1970.tab
southamericazone.tab
America/Chicago 1   zonenow.tab zone1970.tab
northamericazone.tab
America/Denver  1   zonenow.tab zone1970.tab
northamericazone.tab
America/Halifax 1  

Re: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:

I just learned that Ubuntu Noble (24.04) decided to intentionally
split the tzdata package.  Old-style links such as US/Eastern are no
longer included by default, but are available in the tzdata-legacy
package instead.

Just thought I'd share.  I wonder if other distributions / platforms
/ libraries will follow suit.  What do y'all think?

See:
<https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2058249>
<https://stackoverflow.com/questions/78180695/unrecognized-time-zone>



I've been looking at that to reduce Cygwin CI and embedded build server
setup overhead by limiting base install data to:

- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take
advantage of a wide variety of experience in different environments with
different practices and requirements, before making more definite proposals
on the public list.

Please see the attached log for prioritized subsets of tzdata for consideration:
[...]
What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.


We're generating the conversion from Windows to POSIX timezone via
the conversion table from unicode.org:

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org

Plus a few (7, actually) mappings the Unicode consortium missed in
the list (or maybe they are available in the meantime, needs checking).
This is the minimum list of timezone info we need in the tzdata DB.


I generated tzmap.h and generated differences since the last update cldr ~40.
I also searched in the latest for matches for each field attached as first.

I do not know if they will be of help as I see you have already looked at tzmap.

It looks as if the match might better prioritize country code over Windows 
label.

--
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* additional zones - some may now be unnecessary as of latest CLDR 45-a3
  current zones are matched by Windows label, country code, zone id

* { L"E. Europe Standard Time", L"", L"Asia/Nicosia" },
* { L"E. Europe Standard Time", L"CY", L"Asia/Nicosia" },
  { L"E. Europe Standard Time", L"", L"Europe/Chisinau" },
  { L"E. Europe Standard Time", L"MD", L"Europe/Chisinau" },
  { L"GTB Standard Time", L"CY", L"Asia/Nicosia Asia/Famagusta" },

* { L"Eastern Standard Time", L"TC", L"America/Grand_Turk" },
  { L"Eastern Standard Time", L"", L"America/New_York" },
  { L"Eastern Standard Time", L"BS", L"America/Nassau" },
  { L"Eastern Standard Time", L"CA", L"America/Toronto America/Iqaluit" },
  { L"Eastern Standard Time", L"US", L"America/New_York America/Detroit 
America/Indiana/Petersburg America/Indiana/Vincennes America/Indiana/Winamac 
America/Kentucky/Monticello America/Louisville" },
  { L"Eastern Standard Time", L"ZZ", L"EST5EDT" },
  { L"Turks And Caicos Standard Time", L"TC", L"America/Grand_Turk" },
  { L"Turks And Caicos Standard Time", L"", L"America/Grand_Turk" },

* { L"Egypt Standard Time", L"PS", L"Asia/Gaza Asia/Hebron" },
  { L"Egypt Standard Time", L"", L"Africa/Cairo" },
  { L"Egypt Standard Time", L"EG", L"Africa/Cairo" },
  { L"West Bank Standard Time", L"", L"Asia/Hebron" },
  { L"West Bank Standard Time", L"PS", L"Asia/Hebron Asia/Gaza" },

* { L"Greenwich Standard Time", L"EH", L"Africa/El_Aaiun" },
  { L"Greenwich Standard Time", L"", L"Atlantic/Reykjavik" },
  { L"Greenwich Standard Time", L"BF", L"Africa/Ouagadougou" },
  { L"Greenwich Standard Time", L"CI&quo

Fwd: [tz] Ubuntu drops old-style links

[Brian Inglis via Cygwin-apps]

On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:

On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:
I just learned that Ubuntu Noble (24.04) decided to intentionally split the 
tzdata package.  Old-style links such as US/Eastern are no longer included by 
default, but are available in the tzdata-legacy package instead.


Just thought I'd share.  I wonder if other distributions / platforms / 
libraries will follow suit.  What do y'all think?


See:




I've been looking at that to reduce Cygwin CI and embedded build server setup 
overhead by limiting base install data to:


- only the zones in zonenow.tab;
- optionally those in zone1970.tab not in zonenow.tab;
- additionally those in zone.tab in backward, and/or backzone;
- possibly those not in zone.tab, only in backward, and/or backzone;
- additions those in posix subtree, or right subtree.


As tzdata maintainer, I would like to discuss on this list first, to take 
advantage of a wide variety of experience in different environments with 
different practices and requirements, before making more definite proposals on 
the public list.


Please see the attached log for prioritized subsets of tzdata for consideration:

#1 minimal zones required to set the time as it is used around the globe, which 
may require using a different zone id (name) than before, and will be correct 
from release onwards, but possibly not exactly the same historically


#2 extra zones whose clocks have agreed since 1970 and provides correct 
historical times for the zone based on those locations from 1970 onwards


#3 zones which have more, but possibly questionable, historical data

#4 backward compatibility links to other zones, like legacy country based 
directories or regions, or because of renames, splits, data proved uncertain, 
never really correct, never used in the region, was the same as surrounding or 
adjacent regions, or was part of a different country


#5 legacy and historical zone ids

Counts of each are:

pri 1  91 zones src zonenow.tab
pri 2 221 zones src zone1970.tab
pri 3 132 zones src backzone
pri 4 113 zones src backward
pri 5  41 zones src files

There are also the subtrees for posix, which duplicates the base data, in 
contrast to the right subtree which has the same zone names, but provides 
TAI-10s time_t counting leapseconds (currently UTC+27s) ignoring 86400s/day.


The balance is between a proliferation of packages and reasonable selections of 
data, so discussions will be pursued, opinions solicited, possibly debated.


The first package split I propose is tzdata-right, which will include both the 
right and posix subtrees, as few outside the physics communities may need this, 
and we don't know if anyone uses it on Cygwin: yet!


Next for consideration is where the legacy and historical #5 ids fit?
Should they be split into a separate package, or included in a package for 
servers that possibly still use original zones, or require specific GMT offsets, 
like ships at sea?


Then we should look at what to do with the backzone #3 and backward #4 zones 
that offer more historical data, plus backward compatability ids and links, 
which may be useful to the astrological community, and on user desktops.
The backward links could be replaced by instructions taht say if you are using 
link id, use zone id instead.


The zones in #2 allow recent history to be followed and a large number of zones 
that most desktop users are likely to expect to have available.
For me, this includes my local America/Edmonton zone which tracks provincial 
variations in DST observance over the last half century before DST was more 
standardized.


The zones in #1 are limited but reduce minimum install footprint for CI and 
servers that may use few zones other than the built in UTC default.

For me, that means I would have to select America/Denver to get MT with NA DST.
The practice would be similar in Europe: most Europeans would have to select 
Europe/Berlin, as that is the most populous city using that time zone.
Would this be a good place to add #5 in case legacy zone ids are used on server 
builds?


What would the impact on tzset conversion from Windows to Olson tzdb be?
We would probably have to add all of these in to any minimal install.
I think I looked at that somewhere, sometime, not too long ago.

All questions, comments, and suggestions will be greatfully received and 
responded to.


--
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éryAfrica/Abidjan  1   zonenow.tab zone1970.tab

Re: [cygport] enabling a replacement for "objdump -d -l"

[Brian Inglis via Cygwin-apps]

On 2024-03-12 11:49, ASSI via Cygwin-apps wrote:

Jon Turney via Cygwin-apps writes:

But I'm not being oblique here. I really do want comments.


Well, adding comments or proper POD is about the same effort, so I'd
tend towards the latter.


I'm not sure what's so astounding about the suggestion that a fifty
line script should have some comments in it that you can't believe I
mean that literally...


As the saying goes: Communication is possible, but improbable…


Well, OK.  This is less useful to people who actually want to use it,
though, requiring them to know that
"DWARF_PARSE=/usr/share/cygport/tools/dwarf-parse.pl" is the right
incantation.

Perhaps "DWARF_PARSE=1" could be a shorthand for that?


[Sorry still makes me think Dwarvish and Runes e.g.
https://www.evertype.com/standards/iso10646/pdf/cirth.pdf
and if you say ELF I still think zwolf, dreizehn, ... ;^> ]


I don't see why not, it just requires one extra test.


Maybe even more meaningful names, to those of us not so familiar with binutils 
and compiler debug esoterica, stating the connection between the build and the 
function, something like debuginfo_fast_source_filter.pl and 
DEBUGINFO_FAST_SOURCE_FILTER flag, default on if .pl installed?


--
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

[ATTN: Maintainers] oss-sec: Vulnerabilities in FontTools & FontForge

[Brian Inglis via Cygwin-apps]

https://www.canva.dev/blog/engineering/fonts-are-still-a-helvetica-of-a-problem/

https://seclists.org/oss-sec/2024/q1/195

https://github.com/fonttools/fonttools/releases/tag/4.43.0

https://github.com/fontforge/fontforge/pull/5367

--
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: [ATTN. MAINTAINER] units

[Brian Inglis via Cygwin-apps]

On 2024-03-04 12:54, ASSI via Cygwin-apps wrote:

The postinstall script for units downloads currency exchange rates and
hangs up for a long time if it can't access the server (if it ever
finishes, I've killed the process on all machines where I've seen this).
Can this part please either be removed entirely or moved into a
sub-package that doen't get installed by default?


Hi Achim,

Sorry I thought I had dropped that in favour of mentioning it in release notes.

I know some sources have changed so may again be causing an issue.
I will review and release -2 when I get a chance so I do not forget in future.

Can anyone recommend robust tests for network and also site access that I could 
add?


--
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: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Brian Inglis via Cygwin-apps]

On 2024-03-04 13:00, Jon Turney wrote:

On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote:

On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote:

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:
I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR 
is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH.

Is this likely to be upstream (e.g. gnulib) changes or cygport changes?


This is a shortcoming of cygport, in that you cannot just write "do the 
standard src_(compile|install|test), but do this extra thing first (like 
modifying PATH as you need in this case).


(One approach to this I've though about would be to have a hook function (or 
set of functions) which are called before each phase of operation, to allow 
this)


These test failures have been only in the latest upstream releases.
Previously no PATH fiddling was required.
For mingw64-x86_64-nghttp2 that was 2024-01-21.

Why I asked if anyone noticed any cross build changes as for example in 
autotools, gnulib, or cygport?


I assumed that you were talking about "PATH needs to be set so that dependencies 
of the built DLL can be loaded"


But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies.

So, I'm not so sure. Maybe you just mean that the test harness can't locate the 
just built DLL? That could well be an upstream change.


Maybe you could show the actual error?


Sorry I was not clearer.
In previous release build checks there were no issues.
In the latest release the test programs have a dependency on winpthreads and 
failed with popup dialogues:


main.exe - System Error ...
ALSO
failmalloc.exe - System Error
X
The code execution cannot proceed because
libwinpthread-1.dll was not found.
Reinstalling the program may fix this problem.

$ cygcheck -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll
mingw64-x86_64-winpthreads-11.0.1-1

Similar result as:

$ cygcheck mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/{main,failmalloc}
cygcheck: track_down: could not find libwinpthread-1.dll

C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/main.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll

cygcheck: track_down: could not find libwinpthread-1.dll

C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/failmalloc.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll
$ PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/bin/:$PATH"\
cygcheck mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/{main,failmalloc}
C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/main.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll
  C:/.../usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll

C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/failmalloc.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll
  C:/.../usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll

--
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: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Brian Inglis via Cygwin-apps]

On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote:

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:
I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR 
is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH.

Is this likely to be upstream (e.g. gnulib) changes or cygport changes?


This is a shortcoming of cygport, in that you cannot just write "do the standard 
src_(compile|install|test), but do this extra thing first (like modifying PATH 
as you need in this case).


(One approach to this I've though about would be to have a hook function (or set 
of functions) which are called before each phase of operation, to allow this)


These test failures have been only in the latest upstream releases.
Previously no PATH fiddling was required.
For mingw64-x86_64-nghttp2 that was 2024-01-21.

Why I asked if anyone noticed any cross build changes as for example in 
autotools, gnulib, or cygport?


--
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

mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Brian Inglis via Cygwin-apps]

Hi folks,

I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR is 
not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH.

Is this likely to be upstream (e.g. gnulib) changes or cygport changes?

--
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: [PATCH cygport] Use correct wording if only one package is announced

[Brian Inglis via Cygwin-apps]

On 2024-02-21 07:25, Christian Franke via Cygwin-apps wrote:

Change variable name from $s to $has or $s_have as variable $s usually implies 
only the plural letter s or nothing; e.g.

...
+   local has="s have"
+
+   [ $pkg_count != 1 ] || has=" has"
...
+The following package${has} been uploaded to the Cygwin distribution:
...
--
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

libuv 1.48.0 fixes CVE-2024-24806

[Brian Inglis via Cygwin-apps]

All releases >= 1.24.0 confirmed as affected includes all Cygwin releases

https://seclists.org/oss-sec/2024/q1/124

glibc drops libcrypt recommends libxcrypt

[Brian Inglis via Cygwin-apps]

Perhaps time for an update to libxcrypt and libcrypt-devel 4.4.36?

--
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

tzdata 2024a released and will be updated this weekend

[Brian Inglis via Cygwin-apps]

This may affect python3*-pytz, postgresql, or other packages.

--
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: ncurses version

[Brian Inglis via Cygwin-apps]

On 2024-01-31 16:05, Jon Turney via Cygwin-apps wrote:

On 31/01/2024 20:45, Brian Inglis via Cygwin-apps wrote:

On 2024-01-31 10:36, ASSI via Cygwin wrote:

Jon Turney via Cygwin writes:

If upstream really is making multiple releases called '6.4', which
we're supposed to distinguish by some other means, then there aren't
really any good answers...



There's only one official 6.4 release, but just about everyone packages
one of the roughly weekly snapshots inbetween releases (depending on
where you are looking they are also called beta versions), which are
named 6.4-mmdd upstream.  We can't have a "-" in the version number,
hence the suggestion to replace it with a "+".


[moving discussion to -apps]

Upstream developer is Thomas Dickey at invisible-island.net so no git.

My only concern is if 6.4+20240203-1 !> 6.4-20240120 as strvercmp test beds 
disagree, presumably about the effect of the delimiter, possibly because the + 
may be treated similarly to a prefix for an RC preceding the 6.4 release?


For guidance I have looked at:

 https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/

which states that ~ prefixes pre-stable "snapshot" releases and ^ prefixes 
post-stable "snapshot" releases where . or nothing prefixes upstream bugfix or 
patch level releases, so perhaps we should just use version suffix .mmdd?


So, this is notionally defined here [1].

The important point there "Non-alphanumeric separators for these contiguous 
chunks are ignored" (after identifying chunks)


So '1.2.3' '1+2+3' and '1_2_3' are all equal.

[1] https://cygwin.com/packaging-package-files.html#naming

Practically, this is controlled by the version comparison which libsolv does, 
which I am expecting to also work like that.


(Perhaps naively. All the details are paged-out at the moment. I think I 
remember there's a flag which you have to give it to turn on the special 
behaviour of tilde and caret, which in any case aren't currently in the 
character set permitted for a cygwin package name)


I have downloaded and locally installed Fedora rpmdevtools package but Cygwin 
python rpm module seems to lack labelCompare():


$ rpmdev-vercmp 6.4+20240203-1 6.4-20240120
/usr/local/lib/python3.9/site-packages/rpm.py:15: UserWarning: The RPM Python 
bindings are not currently available via PyPI.


This can't be cygwin's python rpm module if it's in /usr/local/, I think?


Thanks for the hint Jon, maybe a pip dependency install needs removed, now 
works:

$ rm -f /usr/local/lib/python3.9/site-packages/rpm.py
removed '/usr/local/lib/python3.9/site-packages/rpm.py'
$ rm -rf /usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/
removed '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/INSTALLER'
removed '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/LICENSE'
removed '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/METADATA'
removed '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/RECORD'
removed '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/REQUESTED'
removed '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/WHEEL'
removed directory '/usr/local/lib/python3.9/site-packages/rpm-0.0.2.dist-info/'
$ rpmdev-vercmp 6.4+20240203-1 6.4-20240120
6.4+20240203-1 > 6.4-20240120


If you have calm installed, you can use:


$ calm-tool sort-versions 1.2.1 1.2.3 1+2+3 1_2_3 1.2.4
1.2.1
1.2.3 1+2+3 1_2_3
1.2.4


Thanks for that too, also works:

$ calm-tool sort-versions 6.4+20240203-1 6.4-20240120; echo
6.4-20240120
6.4+20240203-1


At this point it should be clear that 6.4+2024012 is greater than 6.4.

How are Cygwin pre-stable RC releases defined differently from post-stable 
snapshot releases and upstream patch releases?


Generally, I think that following [2], as linked from that, is a good idea. i.e.

for pre-release versions use R="0." followed by  something that's going to 
increase as prereleases do e.g. date or an incrementing ordinal and then a githash.


for post-releases you can increment R and add a similar identifier.

You can instead add things to V to indicate post-label snapshots, but there's 
there's a risk of coming unstuck unless the upstream versioning scheme is 
totally predicable (i.e. if you create 1.2+3 for a post-release fix to 1.2, and 
then upstream releases a 1.2a which you weren't expecting because they've never 
done it before, you're boned)


[2] https://fedoraproject.org/wiki/Package_Versioning_Examples


Saw that before and know from Debian there is a need for "epoch:" prefix there.

Made necessary changes, reran local and GH Scallywag builds, and uploaded 
unannounced test release, to check all works okay behind the scenes.

Will not push master until ready to make another stable release.

Will copy this approach going forward with other i-i.net and upstream packages 
with major.minor-date releases when updated.


--
Take care. T

Re: ncurses version (was: Tmux crashes on copy)

[Brian Inglis via Cygwin-apps]

On 2024-01-31 10:36, ASSI via Cygwin wrote:

Jon Turney via Cygwin writes:

If upstream really is making multiple releases called '6.4', which
we're supposed to distinguish by some other means, then there aren't
really any good answers...



There's only one official 6.4 release, but just about everyone packages
one of the roughly weekly snapshots inbetween releases (depending on
where you are looking they are also called beta versions), which are
named 6.4-mmdd upstream.  We can't have a "-" in the version number,
hence the suggestion to replace it with a "+".


[moving discussion to -apps]

Upstream developer is Thomas Dickey at invisible-island.net so no git.

My only concern is if 6.4+20240203-1 !> 6.4-20240120 as strvercmp test beds 
disagree, presumably about the effect of the delimiter, possibly because the + 
may be treated similarly to a prefix for an RC preceding the 6.4 release?


For guidance I have looked at:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/

which states that ~ prefixes pre-stable "snapshot" releases and ^ prefixes 
post-stable "snapshot" releases where . or nothing prefixes upstream bugfix or 
patch level releases, so perhaps we should just use version suffix .mmdd?


I have downloaded and locally installed Fedora rpmdevtools package but Cygwin 
python rpm module seems to lack labelCompare():


$ rpmdev-vercmp 6.4+20240203-1 6.4-20240120
/usr/local/lib/python3.9/site-packages/rpm.py:15: UserWarning: The RPM Python 
bindings are not currently available via PyPI.


Please install them with your distro package manager (typically called
'python2-rpm' or 'python3-rpm'), and ensure that any virtual environments
needing the API are configured to be able to see the system site packages
directory.

  warnings.warn(warning_msg)
Traceback (most recent call last):
  File "/home/BWI/bin/rpmdev-vercmp", line 121, in 
main()
  File "/home/BWI/bin/rpmdev-vercmp", line 108, in main
rc = rpm.labelCompare((e1 or None, v1 or None, r1 or None),
AttributeError: module 'rpm' has no attribute 'labelCompare'

I also pip3 installed SAS SW rpm_vercmp which seems okay:

$ python3 -c 'import 
rpm_vercmp;print(rpm_vercmp.vercmp("6.4+20240203-1","6.4-20240120"))

'
1

and wrote a wrapper for shell script functions I found which agrees:

$ ~/src/fedora/rpm-ver.bash 6.4+20240203-1 6.4-20240120
0 6 4 20240203 1
0 6 4 20240120
6.4+20240203-1   6.4-20240120
0 6 4 20240203 1 0 6 4 20240120
sizes 5 4 max 5
20240203 != 20240120
8 ? 8
1

How are Cygwin pre-stable RC releases defined differently from post-stable 
snapshot releases and upstream patch releases?


--
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: [ITA] ncompress 5.0

[Brian Inglis via Cygwin-apps]

On 2024-01-28 09:49, Jon Turney via Cygwin-apps wrote:

On 26/01/2024 14:04, Brian Inglis via Cygwin-apps wrote:
Noticed mention of ncompress used, saw it was unmaintained, occasionally use 
it for old sources, although it appears that gzip also decompresses compress 
.Z, pack .z, and zip single file formats.

Mike F/vapier has migrated ncompress from SF to Github and updated it.
It is available in Fedora up to date.
I updated the current build URIs to current GH and Fedora, rebuilt current 
thru latest versions with patch updates, both locally and on GH scallywag, and 
got the tests working, so I would like to adopt ncompress and provide the 
upgrade.

If accepted, I will follow up patches with current developer.
Cygport and Patch Updates:
 https://cygwin.com/cgit/cygwin-packages/ncompress/?h=playground



Thanks. Looks good.
Can you rebase your changes on top of the git history in main/master?


Sure; I could not find the ncompress repo when I looked for it, so init-ed a new 
one with the standard upstreams.



FEDORA=http://pkgs.fedoraproject.org/cgit/$NAME.git/plain
FEDORA=https://src.fedoraproject.org/rpms/ncompress/raw/f39/f



Obviously the first one here is redundant
#   $FEDORA/$NAME-4.2.4.4-filenamelen.patch
#   $FEDORA/$NAME-4.2.4.4-silence-gcc.patch
#   $FEDORA/$NAME-4.2.4.4-make.patch
#   $FEDORA/$NAME-4.2.4.4-2GB.patch
#   $FEDORA/$NAME-4.2.4.4-endians.patch
#   $FEDORA/$NAME-4.2.4.4-memmove.patch
#   $FEDORA/$NAME-4.2.4.4-lfs.patch
#   $NAME-4.2.4.5-lfs.patch
#   $NAME-4.2.4.6-lfs.patch
#   ncompress-4.2.4.5-runtests-sh-run-from-build-dir.patch
This doesn't seem to have any value, especially as it's in the history...


Never sure if pushes to ncompress/playground would work so kept old stuff around 
in case I had to use playground/playground instead.

Will clean up for rebase onto master.


I added this to your packages.


Thanks Jon

--
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

[ITA] ncompress 5.0

[Brian Inglis via Cygwin-apps]

Hi folks,

Noticed mention of ncompress used, saw it was unmaintained, occasionally use it 
for old sources, although it appears that gzip also decompresses compress .Z, 
pack .z, and zip single file formats.


Mike F/vapier has migrated ncompress from SF to Github and updated it.
It is available in Fedora up to date.
I updated the current build URIs to current GH and Fedora, rebuilt current thru 
latest versions with patch updates, both locally and on GH scallywag, and got 
the tests working, so I would like to adopt ncompress and provide the upgrade.


If accepted, I will follow up patches with current developer.

Scallywag Jobs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ncompress=Brian+Inglis

Cygport and Patch Updates:

https://cygwin.com/cgit/cygwin-packages/ncompress/?h=playground

Build 5.0:

https://github.com/cygwin/scallywag/actions/runs/7668163283/job/20899585246

Available everywhere, sometimes base, sometimes optional:

https://repology.org/project/ncompress/versions

--
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

Fwd: [Bug target/108521] gcc/doc/invoke.texi contains remnants of Cygwin options removed in 2010-10-07

[Brian Inglis via Cygwin-apps]

Yay! At last!
 Forwarded Message 
Subject: [Bug target/108521] gcc/doc/invoke.texi contains remnants of Cygwin 
options removed in 2010-10-07

Date: Thu, 18 Jan 2024 19:41:13 +
From: cvs-commit at gcc dot gnu.org 

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108521

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore:

https://gcc.gnu.org/g:b6c4fcda7fea2c6e14f539780f976bdc1d2591fb

commit r14-8259-gb6c4fcda7fea2c6e14f539780f976bdc1d2591fb
Author: Brian Inglis
Date:   Thu Jan 18 19:29:01 2024 +

Remove remnant of removed Cygwin options from invoke.texi [PR108521]

The -mcygwin option for x86 Windows was removed in 2010 by commit
3edeb30d044a4852881c34229e618b34f95b0d9e, but this reference was
overlooked.

gcc/ChangeLog
PR target/108521
* doc/invoke.texi (Option Summary): Remove -mcygwin and -mno-cygwin
from x86 Windows Options.

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

--
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: Automatic announcement generation by calm

[Brian Inglis via Cygwin-apps]

On 2024-01-08 06:01, Thomas Wolff via Cygwin-apps wrote:

Am 08/01/2024 um 13:35 schrieb Corinna Vinschen via Cygwin-apps:

On Jan  7 16:12, Jon Turney via Cygwin-apps wrote:

This is an experimental facility, currently only available for packages
deployed from the build service [1] (that is, not for self-built packages
uploaded with 'cygport up' via sftp)

When the token "announce" is present for a build job (in addition to
"deploy"), after a successful deploy, calm will automatically generate and
send an announce email.

The mail follows a similar format to that generated by "cygport announce",
containing a list of packages and the description, with the following
addition:


Maybe also append:
"
For more information, see the project home page:

$HOMEPAGE
"


* If the cygport defines the variable "ANNOUNCE", it's evaluated contents
will be appended to the generated mail.


Evaluated how - cygport variable expansion - commands?

Could ANNOUNCE variable contain a source file name or a URI?


* Otherwise, if the source package contains an ANNOUNCE file [2], it's
contents will be appended.


Could ANNOUNCE be a symlink to $NAME-$PVR.$ARCH/origsrc/$SRC_DIR/NEWS?


* Otherwise, if the source package contains a README or ${PN}.README file,
lines that look like part of a changelog, between one starting with '
${PVR}' and the next starting '', will be extracted and appended

(None of these seem like a particularly great way of doing things, but they
match some historical patterns.  As always, suggestions about improvements
are welcome.)


In accordance with our long-standing policy of treating maintainer email
addresses as private information, the mail is sent from cygwin-no-reply and
bcc'ed to the uploader.


How about email headers:

From: "Cygwin $NAME Maintainer" 
To: Cygwin Announcements 
Bcc: $SMTP_SENDER
Reply-To: Cygwin 
Subject: Updated: $NAME $PVR


For testing purposes, if the token "mock" (yes, I am running out of synonyms
for "test"...) is also present, the mail will be only sent to the uploader,
not the announce list.


[1] https://cygwin.com/packaging/build.html
[2] Note that this isn't currently part of the default value of CYGWIN_FILES
[3], so needs to be explicitly listed there to be included in the source
package
[3] https://cygwin.github.io/cygport/src_prep_cygpart.html#CYGWIN_FILES

:+1:

Unfortunately I started the OpenSSH 9.6 build before reading this here,
but that's some great addition.


I'd also appreciate to prefix the mail with an "[ANNOUNCEMENT] " tag as for the 
mails forwarded from cygwin-announcement to cygwin before that was stopped, to 
enhance the overview in users' mailboxes.


Spammy looking compared to "Updated: ..."?

Maybe also update cygport ... announce to be as close as possible to calm?

--
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: github scallywag cygport src_patch_apply_hook and autoconf2.7 install issues

[Brian Inglis via Cygwin-apps]

On 2024-01-06 14:16, Jon Turney via Cygwin-apps wrote:

On 06/01/2024 20:10, Brian Inglis via Cygwin-apps wrote:
Updating gsasl to 2.2.1 local package build runs fine, but github scallywag 
now fails in two places:


- cygport src_prep src_patch_apply_hook now fails to find patch file passed as 
$1:



I've looked at the cygport, but what you're doing here is very confusing.

Even with the poor state of the documentation for that hook [1], the fact that 
this hook doesn't take any care over the result it returns is a red flag.


[1] https://cygwin.github.io/cygport/src_prep_cygpart.html#src_patch_apply_hook

(So it seems like maybe it should 'patch || error', and then return 0)

It seems like this cygport is written making some assumption about the current 
directory when this hook is run, that it's the top-level directory containing 
the patch files.


I could understand that's maybe been accidentally changed from a previous 
version with some other change to cygport, but I don't quite understand how that 
can be true locally.


However, it's certainly not guaranteed, because this hook was not designed for 
you to do your own patch application like this in.


All that said: If you write '${top}/$1' it works for me, but you absolutely 
shouldn't be relying on undocumented cygport internals like that...


Thanks Jon,

The issues with using these hooks is a given!

I will try that path in the cygport hook, locally and in scallywag.

Is there some other way in which I could structure the patch to apply to the out 
of tree installed gtk-doc makefiles prior to the build without using the hook?


The issue with gtk-doc failing this build was discussed when found, in -apps 
2022-09-29/30, and applying the patch to its makefiles seemed to be the best way 
to handle it at the time.


I submitted gsasl and gtk-doc patches upstream at the time but had more check 
FAILs than PASSes after updating gtk-doc.




```
 >>> Preparing gsasl-2.2.1-1.x86_64
 >>> Unpacking source gsasl-2.2.1.tar.gz
patch -b /usr/share/gtk-doc/data/gtk-doc.flat.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
patch -b /usr/share/gtk-doc/data/gtk-doc.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
patch -b /usr/share/gtk-doc/data/gtk-doc.no-xslt-flat.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
patch -b /usr/share/gtk-doc/data/gtk-doc.no-xslt.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
*** Warning: patch gsasl-2-gtk-doc-make-pdf-imgdir.patch skipped by 
src_patch_apply_hook

 >>> Preparing working source directory
```

- autoconf2.7 is not found, although it is in cygport dependencies, installed 
in step 4 cygwin install action, with 42 dependencies expanded to 232 install 
tasks, and package BUILD_REQUIRES, with 29 dependencies expanded to 259 
install tasks, excluding autoconf, but build fails:

```
 >>> Compiling gsasl-2.2.1-1.x86_64
*** ERROR: autoconf2.7 is required to build this package
```



This seems to be some breakage from today's update to autoconf 2.72.

Top Men, working on, etc.


Thanks, I just noticed the release and wrapper update announcements.

--
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

github scallywag cygport src_patch_apply_hook and autoconf2.7 install issues

[Brian Inglis via Cygwin-apps]

Updating gsasl to 2.2.1 local package build runs fine, but github scallywag now 
fails in two places:


- cygport src_prep src_patch_apply_hook now fails to find patch file passed as 
$1:
```
>>> Preparing gsasl-2.2.1-1.x86_64
>>> Unpacking source gsasl-2.2.1.tar.gz
patch -b /usr/share/gtk-doc/data/gtk-doc.flat.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory

patch -b /usr/share/gtk-doc/data/gtk-doc.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
patch -b /usr/share/gtk-doc/data/gtk-doc.no-xslt-flat.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
patch -b /usr/share/gtk-doc/data/gtk-doc.no-xslt.make 
gsasl-2-gtk-doc-make-pdf-imgdir.patch
patch:  Can't open patch file gsasl-2-gtk-doc-make-pdf-imgdir.patch : No 
such file or directory
*** Warning: patch gsasl-2-gtk-doc-make-pdf-imgdir.patch skipped by 
src_patch_apply_hook

>>> Preparing working source directory
```

- autoconf2.7 is not found, although it is in cygport dependencies, installed in 
step 4 cygwin install action, with 42 dependencies expanded to 232 install 
tasks, and package BUILD_REQUIRES, with 29 dependencies expanded to 259 install 
tasks, excluding autoconf, but build fails:

```
>>> Compiling gsasl-2.2.1-1.x86_64
*** ERROR: autoconf2.7 is required to build this package
```

Cygport and patch in:
https://cygwin.com/cgit/cygwin-packages/gsasl/tree/

Job log at:
https://github.com/cygwin/scallywag/actions/runs/7433276878/job/20226196620

--
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: [ITA] pocl

[Brian Inglis via Cygwin-apps]

On 2024-01-03 05:00, Takashi Yano via Cygwin-apps wrote:

On Wed, 3 Jan 2024 04:38:02 -0700
Brian Inglis wrote:

On 2024-01-03 02:29, Takashi Yano via Cygwin-apps wrote:

On Wed, 3 Jan 2024 08:54:17 +0100
Marco Atzeri wrote:

On 03/01/2024 06:25, Takashi Yano via Cygwin-apps wrote:

On Wed, 3 Jan 2024 14:14:12 +0900
Takashi Yano via Cygwin-apps  wrote:

I'd like to adopt the pocl package.
- Update to latest upstream release.



$ git diff  |grep "^+"
+++ b/cygwin-pkg-maint
+pocl Takashi Yano



Sorry, the latest upstream release is 5.0 however, 4.0 and later
cannot be built in current cygwin because LLVM package is old.
This update is up to 3.1.



- Enable CUDA support.



Curiosity, how do we support CUDA on Cygwin ?



nvidia cuda toolkit is used in build stage of user programs.
Although this is not very desirable for cygwin package, I thought
that the advantage of being able to use the GPU was greater than
the disadvantage.
However, on the second thought, cuda support should be a separeted
package from the base package, and suggest installing cuda toolkit
in the install stage of of that package.
Let me consider a bit. If you have any idea, please let me know.


Please note CUDA is Nvidia proprietary closed source - I do not think we can or
should touch it when OpenCL 3+ supports Nvidia devices.
Fedora does not support CUDA although others do in their non-free "sources".


We do not touch CUDA itself or distribute its binaries, but just use binaries
distributed by NVIDIA. Source code in pocl is not NVIDIA proprietary. In that
sense, cygwin itself uses microsoft proprietary closed source modules.


Cygwin provides and runs open source tools, headers, and libraries to perform 
the builds and execution, calling proprietary interfaces to support POSIX.



So, enabling CUDA support in pocl should also be allowed, I think.


I believe not if the Nvidia tools do not have sources available to build with 
Cygwin tools built from sources.

--
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: [ITA] pocl

[Brian Inglis via Cygwin-apps]

On 2024-01-03 02:29, Takashi Yano via Cygwin-apps wrote:

On Wed, 3 Jan 2024 08:54:17 +0100
Marco Atzeri wrote:

On 03/01/2024 06:25, Takashi Yano via Cygwin-apps wrote:

On Wed, 3 Jan 2024 14:14:12 +0900
Takashi Yano via Cygwin-apps  wrote:

I'd like to adopt the pocl package.
- Update to latest upstream release.



$ git diff  |grep "^+"
+++ b/cygwin-pkg-maint
+pocl Takashi Yano



Sorry, the latest upstream release is 5.0 however, 4.0 and later
cannot be built in current cygwin because LLVM package is old.
This update is up to 3.1.



- Enable CUDA support.



Curiosity, how do we support CUDA on Cygwin ?



nvidia cuda toolkit is used in build stage of user programs.
Although this is not very desirable for cygwin package, I thought
that the advantage of being able to use the GPU was greater than
the disadvantage.
However, on the second thought, cuda support should be a separeted
package from the base package, and suggest installing cuda toolkit
in the install stage of of that package.
Let me consider a bit. If you have any idea, please let me know.


Please note CUDA is Nvidia proprietary closed source - I do not think we can or 
should touch it when OpenCL 3+ supports Nvidia devices.

Fedora does not support CUDA although others do in their non-free "sources".

--
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

groff docs

[Brian Inglis via Cygwin-apps]

Attn Groff Maintainer (Hi Achim),

Please consider including in DOCS files BUG_REPORT and PROBLEMS referred by 
BUG_REPORT with suggestions for dealing with common issues like hyphen-minus 
(came up on mintty) and pagers, licences FDL and LICENSES, and file MORE.STUFF 
which suggests sources for other preprocessors not included and other converters 
and related utilities.


--
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: [scallywag] libksba-1.6.5-1 install anomaly

[Brian Inglis via Cygwin-apps]

On 2023-12-18 22:29, Marco Atzeri via Cygwin-apps wrote:

on jobs 7426 and (rerun) 7428 I see that a file is built
but not installed
--
config.status: creating src/ksba-config
...
 >>> libksba-devel-1.6.5-1.tar.xz
tar: usr/bin/ksba-config: Cannot stat: No such file or directory
--
but if I run exacly the same jobs locally, the file is installed and
packed as expected
$ find libksba-1.6.5-1.x86_64 -name ksba-config
libksba-1.6.5-1.x86_64/build/src/ksba-config
libksba-1.6.5-1.x86_64/inst/usr/bin/ksba-config
$ grep -H ksba-config libksba-1.6.5-1.x86_64/log/*
libksba-1.6.5-1.x86_64/log/libksba-1.6.5-1-compile.log:config.status: creating 
src/ksba-config
libksba-1.6.5-1.x86_64/log/libksba-1.6.5-1-install.log: /usr/bin/install -c 
ksba-config '/pub/devel/libksba/libksba-1.6.5-1.x86_64/inst/usr/bin'

libksba-1.6.5-1.x86_64/log/libksba-1.6.5-1-pkg.log:usr/bin/ksba-config
Any clue if I should add something to the
BUILD_REQUIRES="libgpg-error-devel pkg-config"
the only difference between system I can think about is
case Sensitive file system.
But I can not test it as my system loses some functionality
like network if I turn all the file system to be case sensitive


I use standard /usr/src/ for packages, sources, and builds, and chattr -R +S ... 
which makes it easier dealing with Linux man-pages and like packages.


--
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: [NMU] inkscape 0.92.3-2 (Test)

[Brian Inglis via Cygwin-apps]

On 2023-12-06 10:19, Brian Inglis via Cygwin-apps wrote:

On 2023-12-05 06:07, Jon Turney wrote:

On 03/12/2023 17:50, Brian Inglis via Cygwin-apps wrote:

On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:

On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:

If you have ideas about how to make things work better, I'm all ears.
For the moment, I tweaked things to let your upload through.


Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur 
to me that those doing them were explicitly allowed to.
ISTM the process works fine as it is.  If I happen to have a future itch to 
do an NMU should I handle it as I did this one?  Or say something on 
cygwin-apps beforehand?  I don't expect it will be often.  I'm totally fine 
not being on the "trusted" list for this type of thing.


If you ask in advance, that's possibly slightly less work for me, but either 
is fine really.
Maybe I should make things so that all maintainers can NMU orphaned 
packages. That seems reasonable I guess?


Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
"toolchain" defined as cygport and cygwin deps and build deps (i.e. bzip2 
cocom docbook git-archive-all robodoc); maybe also all their deps and build 
deps, even Devel and Libs?


I was kind of hoping that base packages (and "dependencies of packages in base 
which aren't in base themselves") aren't unmaintained, but obviously that was 
being optimistic...


I thought I should take a peek in hopes too, but just in case, not being 
paranoid /much/, but like to have a bigger fan ready just in case! ;^>


Maybe we should work on publishing package adoption priority lists e.g.

1 Base 1.1 crypto-policies 1.2 alternatives
2 Build 1.1 cocom (now dino) 1.2 git-archive-all 1.3 robodoc 1.4 bzip2
 1.5 docbook... [lots of Unmaintained pkgs and deps]

  2 Build 2.1 cocom (now dino) 2.2 git-archive-all 2.3 robodoc 2.4 bzip2
   2.5 docbook... [lots of Unmaintained pkgs and deps]

3 Base direct deps

  3 Base direct deps 3.1 ...

4 Build direct deps

  4 Build direct deps 4.1 ...

5 Base indirect deps

  5 Base indirect deps 5.1 ...

6 Build indirect deps

  6 Build indirect deps 6.1 ...


I stopped once I looked at docbook...sob...! ;^>


[Getting coffee now!]

--
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: [NMU] inkscape 0.92.3-2 (Test)

[Brian Inglis via Cygwin-apps]

On 2023-12-05 06:07, Jon Turney wrote:

On 03/12/2023 17:50, Brian Inglis via Cygwin-apps wrote:

On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:

On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:

If you have ideas about how to make things work better, I'm all ears.
For the moment, I tweaked things to let your upload through.


Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur to 
me that those doing them were explicitly allowed to.
ISTM the process works fine as it is.  If I happen to have a future itch to 
do an NMU should I handle it as I did this one?  Or say something on 
cygwin-apps beforehand?  I don't expect it will be often.  I'm totally fine 
not being on the "trusted" list for this type of thing.


If you ask in advance, that's possibly slightly less work for me, but either 
is fine really.
Maybe I should make things so that all maintainers can NMU orphaned packages. 
That seems reasonable I guess?


Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
"toolchain" defined as cygport and cygwin deps and build deps (i.e. bzip2 
cocom docbook git-archive-all robodoc); maybe also all their deps and build 
deps, even Devel and Libs?


I was kind of hoping that base packages (and "dependencies of packages in base 
which aren't in base themselves") aren't unmaintained, but obviously that was 
being optimistic...


I thought I should take a peek in hopes too, but just in case, not being 
paranoid /much/, but like to have a bigger fan ready just in case! ;^>


Maybe we should work on publishing package adoption priority lists e.g.

1 Base 1.1 crypto-policies 1.2 alternatives
2 Build 1.1 cocom (now dino) 1.2 git-archive-all 1.3 robodoc 1.4 bzip2
1.5 docbook... [lots of Unmaintained pkgs and deps]
3 Base direct deps
4 Build direct deps
5 Base indirect deps
6 Build indirect deps

I stopped once I looked at docbook...sob...! ;^>

--
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: [PATCH cygport] git.cygclass: Suppress the depth option

[Brian Inglis via Cygwin-apps]

On 2023-12-03 13:34, Jon Turney via Cygwin-apps wrote:

On 30/11/2023 12:17, Daisuke Fujimura via Cygwin-apps wrote:

Implementations that conditionally branch on variables are simple.

The proposed retry implementation complicates git.cygclass, but I
think it reduces the maintainer's effort.

I have created a patch for a retry implementation.
Could you review it?


Thanks very much.

Sure.


diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..1e26ab37 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -76,19 +76,33 @@ git_fetch() {
   # (not allowed for a hash, unless remote is configured to permit
   # it with allow*SHA1InWant).
   _depth="--depth 1"
+ _branch=""


I think this is not necessary, as expanding an undefined variable is permitted 
and has the equivalent empty value.



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


I think this wants to be _branch, as otherwise that used but never defined?


   elif defined GIT_BRANCH
   then
- _depth+=" --branch ${GIT_BRANCH}"
+ _depth=" --branch ${GIT_BRANCH}"


Likewise.


   fi
   fi

   # T likely doesn't exist at this point, so create it first
   mkdir -p ${T}
   cd ${T}
- verbose git clone ${_depth} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ _gitlog=${T}/git.$$.log
+ verbose git clone ${_depth} ${_branch} --no-checkout ${GIT_URI}
${GIT_MODULE} |& tee ${_gitlog}
+ if [ ${PIPESTATUS[0]} != 0 ]
+ then
+ grep "fatal: dumb http transport does not support shallow
capabilities" ${_gitlog} >& /dev/null


Can't this just use 'grep -q' ?

I wonder if there's a locale issue here (i.e. will git produce a localized error 
message if LANG etc. is defined?)


Maybe depending on the precise string is too fragile, and we should just 
unconditionally retry to see if things get better?



+ if [ $? = 0 ]
+ then
+ warning "git clone failed, retry without --depth option"
+ verbose git clone ${_branch} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ else


In this case, the clone failed for a different reason, but we've eaten the 
output from git, so maybe there's no indication given as to why?


Do we want to do something like "cat ${_gitlog}" here?


+ error "git clone failed"
+ fi
+ fi
   cd ${T}/${GIT_MODULE}

  #v* git.cygclass/GIT_BRANCH


On Mon, Nov 20, 2023 at 11:23 PM Jon Turney  wrote:


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
```


[...]


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).



Attached is the patch after my edits.


Looks like straight curl HEAD -I tells you about smart transport if you want a 
quick check rather than a dry run:


$ time curl -ILSs https://repo.or.cz/r/git.git/info/refs?service=git-upload-pack 
| grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $?


real0m0.630s
user0m0.077s
sys 0m0.123s
0
$ time curl -ILSs 
https://github.com/BrianInglis/apt-cyg.git/info/refs?service=git-upload-pack  | 
grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $?


real0m0.440s
user0m0.061s
sys 0m0.184s
1

--
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: [NMU] inkscape 0.92.3-2 (Test)

[Brian Inglis via Cygwin-apps]

On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:

On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:



If you have ideas about how to make things work better, I'm all ears.

For the moment, I tweaked things to let your upload through.


Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur to 
me that those doing them were explicitly allowed to.


ISTM the process works fine as it is.  If I happen to have a future itch to do 
an NMU should I handle it as I did this one?  Or say something on cygwin-apps 
beforehand?  I don't expect it will be often.  I'm totally fine not being on 
the "trusted" list for this type of thing.


If you ask in advance, that's possibly slightly less work for me, but either is 
fine really.


Maybe I should make things so that all maintainers can NMU orphaned packages. 
That seems reasonable I guess?


Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
"toolchain" defined as cygport and cygwin deps and build deps (i.e. bzip2 cocom 
docbook git-archive-all robodoc); maybe also all their deps and build deps, even 
Devel and Libs?


Any of us or sourceware accounts could be hacked (possibly even targeted), and 
systems used to disrupt Cygwin processes, if someone had some dispute, wanted to 
be nasty, to see if they could do it, or made a mistake.


--
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 upgrade to use gnupg2/gpg2 if available

[Brian Inglis via Cygwin-apps]

On 2023-11-24 14:29, Marco Atzeri via Cygwin-apps wrote:

On 21.11.2023 07:58, ASSI via Cygwin-apps wrote:

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


++1?


should I just retire gpg 1.x and stop having gpg2 as different binary name ?


Or obsolete 1 with 2 and add compatibility symlinks or scripts?

Keep names separate so easy to check.


$ for i in /usr/bin/gpg* ; do echo -n $i " : " ; cygcheck -f $i ; done
/usr/bin/gpg.exe  : gnupg-1.4.23-1
/usr/bin/gpg2.exe  : gnupg2-2.2.35-2
/usr/bin/gpg-agent.exe  : gnupg2-2.2.35-2
/usr/bin/gpgconf.exe  : gnupg2-2.2.35-2
/usr/bin/gpg-connect-agent.exe  : gnupg2-2.2.35-2
/usr/bin/gpg-error.exe  : libgpg-error-devel-1.47-1
/usr/bin/gpgme-config  : libgpgme-devel-1.9.0-1
/usr/bin/gpgme-tool.exe  : libgpgme-devel-1.9.0-1
/usr/bin/gpgparsemail.exe  : gnupg2-2.2.35-2
/usr/bin/gpgrt-config  : libgpg-error-devel-1.47-1
/usr/bin/gpgscm.exe  : gnupg2-2.2.35-2
/usr/bin/gpgsm.exe  : gnupg2-2.2.35-2
/usr/bin/gpgsplit.exe  : gnupg-1.4.23-1
gnupg2-2.2.35-2
/usr/bin/gpgtar.exe  : gnupg2-2.2.35-2
/usr/bin/gpgv.exe  : gnupg-1.4.23-1
/usr/bin/gpgv2.exe  : gnupg2-2.2.35-2
/usr/bin/gpg-wks-server.exe  : gnupg2-2.2.35-2
/usr/bin/gpg-zip  : gnupg-1.4.23-1


gpg-zip is only in 1, gpgsplit is in 1 *AND* 2, but likely 2 is installed over 
1, and a lot of new stuff is in 2:


$ cygcheck -l gnupg | grep bin/
/usr/bin/gpg-zip
/usr/bin/gpg.exe
/usr/bin/gpgsplit.exe
/usr/bin/gpgv.exe
$ cygcheck -l gnupg2 | grep bin/
/usr/bin/dirmngr-client.exe
/usr/bin/dirmngr.exe
/usr/bin/gpg-agent.exe
/usr/bin/gpg-connect-agent.exe
/usr/bin/gpg-wks-server.exe
/usr/bin/gpg2.exe
/usr/bin/gpgconf.exe
/usr/bin/gpgparsemail.exe
/usr/bin/gpgscm.exe
/usr/bin/gpgsm.exe
/usr/bin/gpgsplit.exe
/usr/bin/gpgtar.exe
/usr/bin/gpgv2.exe
/usr/bin/kbxutil.exe
/usr/bin/watchgnupg.exe
/usr/sbin/addgnupghome
/usr/sbin/applygnupgdefaults

--
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 upgrade to use gnupg2/gpg2 if available

[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

[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: Scallywag download includes {-2130706432,-2139095040,-2147483648}_build.txt

[Brian Inglis via Cygwin-apps]

On 2023-10-28 12:04, Jon Turney via Cygwin-apps wrote:

On 28/10/2023 18:15, Brian Inglis via Cygwin-apps wrote:
Scallywag now seems to be including 563 byte 10 line Prepare job build section 
headers in:


 -2130706432_build.txt
 -2139095040_build.txt
 -2147483648_build.txt

instead of the previous {2,4,6}_build.txt


I'm sorry I don't understand. Where are these files?

I don't think I made any changes to scallywag recently, so I'm have no idea what 
the cause here might be.


Those files are now in the GitHub Scallywag job Download log archive instead of 
the previous {2,4,6}_build.txt until at least 2023-10-14 10 lines 563 bytes each 
Prepare job build section headers e.g. for 7152 libvpx since at least 2023-10-21 
we now have:


$ unzip -l logs_2968.zip
Archive:  logs_2968.zip
  Length  DateTimeName
-  -- -   
  705  10-28-2023 18:11   x86_64  build/5_Clean .la files.txt
 2095  10-28-2023 18:11   noarch  build/1_Set up job.txt
 2820  10-28-2023 18:11   noarch  build/6_Build packages.txt
  298  10-28-2023 18:11   noarch  build/2_Run git config --global 
core.autocrlf input.txt

   58  10-28-2023 18:11   source  build/24_Complete job.txt
14138  10-28-2023 18:11   x86_64  build/8_Upload builddir archive.txt
   118567  10-28-2023 18:11   source  build/4_Run 
cygwincygwin-install-act...@master.txt
  298  10-28-2023 18:11   source  build/2_Run git config --global 
core.autocrlf input.txt

 9149  10-28-2023 18:11   x86_64  build/3_Run actionscheck...@v3.txt
  563  10-28-2023 18:11   -2147483648_build.txt
 9149  10-28-2023 18:11   source  build/3_Run actionscheck...@v3.txt
  3642551  10-28-2023 18:11   x86_64  build/6_Build packages.txt
  278  10-28-2023 18:11   noarch  build/10_Avoid actionscheckout post-run 
step using Cygwin git.txt

  414  10-28-2023 18:11   noarch  build/9_Upload packages.txt
   58  10-28-2023 18:11   x86_64  build/24_Complete job.txt
0  10-28-2023 18:11   noarch  build/
   137582  10-28-2023 18:11   0_noarch  build.txt
  563  10-28-2023 18:11   -2130706432_build.txt
  705  10-28-2023 18:11   noarch  build/5_Clean .la files.txt
   58  10-28-2023 18:11   noarch  build/24_Complete job.txt
 1531  10-28-2023 18:11   x86_64  build/20_Post Run actionscheck...@v3.txt
 1801  10-28-2023 18:11   source  build/9_Upload packages.txt
 1772  10-28-2023 18:11   source  build/7_Upload scallywag metadata.txt
0  10-28-2023 18:11   x86_64  build/
  3789853  10-28-2023 18:11   0_x86_64  build.txt
 2095  10-28-2023 18:11   source  build/1_Set up job.txt
  298  10-28-2023 18:11   x86_64  build/2_Run git config --global 
core.autocrlf input.txt

  714  10-28-2023 18:11   noarch  build/8_Upload builddir archive.txt
 1723  10-28-2023 18:11   source  build/20_Post Run actionscheck...@v3.txt
   118567  10-28-2023 18:11   x86_64  build/4_Run 
cygwincygwin-install-act...@master.txt

 9149  10-28-2023 18:11   noarch  build/3_Run actionscheck...@v3.txt
 1723  10-28-2023 18:11   noarch  build/20_Post Run actionscheck...@v3.txt
  563  10-28-2023 18:11   -2139095040_build.txt
  705  10-28-2023 18:11   source  build/5_Clean .la files.txt
 2395  10-28-2023 18:11   source  build/8_Upload builddir archive.txt
   118567  10-28-2023 18:11   noarch  build/4_Run 
cygwincygwin-install-act...@master.txt

 2095  10-28-2023 18:11   x86_64  build/1_Set up job.txt
21868  10-28-2023 18:11   source  build/6_Build packages.txt
  278  10-28-2023 18:11   source  build/10_Avoid actionscheckout post-run 
step using Cygwin git.txt

0  10-28-2023 18:11   source  build/
   161470  10-28-2023 18:11   0_source  build.txt
- ---
  8177216 41 files

I download these after each package build to compare the local and CI build test 
results in case they differ.


--
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

Scallywag download includes {-2130706432,-2139095040,-2147483648}_build.txt

[Brian Inglis via Cygwin-apps]

Scallywag now seems to be including 563 byte 10 line Prepare job build section 
headers in:


-2130706432_build.txt
-2139095040_build.txt
-2147483648_build.txt

instead of the previous {2,4,6}_build.txt

--
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

[PATCH 0/7] cygcheck-dep updates

[Brian Inglis via Cygwin-apps]

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

[Brian Inglis via Cygwin-apps]

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

[ITA] libvpx

[Brian Inglis via Cygwin-apps]

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.


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
158Mlibvpx-1.13.1-1.x86_64/build/test_libvpx.exe
33M libvpx-1.13.1-1.x86_64/build/test_rc_interface.exe
3.3Mlibvpx-1.13.1-1.x86_64/build/vpxdec.exe
3.5Mlibvpx-1.13.1-1.x86_64/build/vpxenc.exe
3.4Mlibvpx-1.13.1-1.x86_64/inst/usr/bin/cygvpx-8.dll
680Klibvpx-1.13.1-1.x86_64/inst/usr/bin/vpxdec.exe
700Klibvpx-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 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

--
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éryscallywag.log-2023-10-26T06:49:56.3847823Z [==] 1597 tests from 163 
test suites ran. (889622 ms total)
scallywag.log:2023-10-26T06:49:56.3848609Z [  PASSED  ] 1597 tests.
scallywag.log-2023-10-26T06:49:56.3849022Z 
--
scallywag.log-2023-10-26T07:06:38.7784829Z Expected: (vd) != (0), actual: 0 vs 0
scallywag.log:2023-10-26T07:06:38.7786023Z [  FAILED  ] 
SSE2/AddNoiseTest.CheckNoiseAdded/1, where GetParam() = (4.4, 0x1008fb000) (0 
ms)
scallywag.log-2023-10-26T07:06:38.7787128Z [--] 1 test from 
SSE2/AddNoiseTest (0 ms total)
--
scallywag.log-2023-10-26T07:06:38.8239538Z [==] 1597 tests from 165 
test suites ran. (1002125 ms total)
scallywag.log:2023-10-26T07:06:38.8240341Z [  PASSED  ] 1596 tests.
scallywag.log:2023-10-26T07:06:38.8240938Z [  FAILED  ] 1 test, listed below:
scallywag.log:2023-10-26T07:06:38.8241955Z [  FAILED  ] 
SSE2/AddNoiseTest.CheckNoiseAdded/1, where GetParam() = (4.4, 0x1008fb000)
scallywag.log-2023-10-26T07:06:38.8242868Z 
scallywag.log:2023-10-26T07:06:38.8243108Z  1 FAILED TEST
scallywag.log-2023-10-26T07:06:38.8243606Z   YOU HAVE 97 DISABLED TESTS
--
scallywag.log-2023-10-26T07:23:13.7914593Z [==] 1597 tests from 164 
test suites ran. (994656 ms total)
scallywag.log:2023-10-26T07:23:13.7915396Z [  PASSED  ] 1597 tests.
scallywag.log-2023-10-26T07:23:13.7915791Z 
--
scallywag.log-2023-10-26T07:36:17.7847729Z   Actual: it does.
scallywag.log:2023-10-26T07:36:17.8969258Z [  FAILED  ] 
VP9/RealtimeTest.IntegerOverflowLarge/0, where GetParam() = (0x100c7c9b8, 0) 
(3454 ms)
scallywag.log-2023-10-26T07:36:17.8973043Z [--] 1 test from 
VP9/RealtimeTest (3454 ms total)
--
scallywag.log-2023-10-26T07:39:15.0357677Z [==] 1597 tests from 165 
test suites ran. (960935 ms total)
scallywag.log:2023-10-26T07:39:15.0358589Z [  PASSED  ] 1596 tests.
scallywag.log:2023-10-26T07:39:15.0359197Z [  FAILED  ] 1 test, listed below:
scallywag.log:2023-10-26T07:39:15.0360270Z [  FAILED  ] 
VP9/RealtimeTest.IntegerOverflowLarge/0, where GetParam() = (0x100c7c9b8, 0)
scallywag.log-2023-10-26T07:39:15.0361191Z 
scallywag.log:2023-10-26T07:39:15.0361456Z  1 FAILED TEST
scallywag.log-2023-10-26T07:39:15.0361945Z   YOU HAVE 15 DISABLED TESTS
--
scallywag.log-2023-10-26T07:39:20.4125625Z   Actual: it does.
scallywag.log:2023-10-26T07:39:20.5227861Z [  FAILED  ] 
VP9FrameSizeTestsLarge.TestInvalidSizes (3469 ms)
scallywag.log-2023-10-26T07:39:20.5229526Z [--] 1 test from 
VP9FrameSizeTestsLarge (3469 ms total)
--
scallywag.log-2023-10-26T07:52:46.8055133Z [==] 1597 tests from 162 
test suites ran. (811457 ms total)
scallywag.log:2023-10-26T07:52:46.8056250Z [  PASSED  ] 1596 tests.
scallywag.log:2023-10-26T07:52:46.8056874Z [  FAILED  ] 1 test, listed below:
scallywag.log:2023-10-26T07:52:46.8057672Z [  FAILED  ] 
VP9FrameSizeTestsLarge.TestInvalidSizes
scallywag.log-2023-10-26T07:52:46.8058333Z 
scallywag.log:2023-10-26T07:52:46.8058581Z  1 FAILED TEST
scallywag.log-2023-10-26T07:52:46.8059085Z   YOU HAVE 

Re: Clean out or vault old ncurses test versions

[Brian Inglis via Cygwin-apps]

On 2023-10-22 14:13, Jon Turney via Cygwin-apps wrote:

On 22/10/2023 16:42, Brian Inglis via Cygwin-apps wrote:


I should probably just skip the sequential "release" prefix to the date suffix,
as 6.4-2023 is presumably greater than 6.4-?.2023, and we have not yet 
implemented EPOCH:V-R dating yet, correct?


Yes, 2023 (where ? stands for some digit) is bigger than any of the numbers 
in the range 4...13.


Epochs are supported (theoretically), but I don't think you need to use them 
here.


...and hopefully they ignore the sequential number.


Again, the question isn't about the meaning that a person ascribes to the 
version number (because you can't reasonably expect people to examine every 
package in detail), it's about the actions that setup will automatically take.



Just to be clear about the process details and best practice:

I should create a dummy local dist tree for superseded versions,
with the tar file names prefixed with "-" and zero length,


You don't need to do this.  This removes files (which I think you have already 
done)



and P-V-R.hint files replaced with override.hint files,
each containing "replace-versions: V-R..." for old versions,
then sftp upload that dist tree in a similar manner to cygport upload?


Yes.

But if you are really going to upload a 6.4-2023MMDD sometime soon (or anything 
greater than 6.4-13, in fact), you don't need to bother, because that does 
supersede the removed test versions (and so any installation of them will get 
upgraded).


Thanks Jon,

I probably will do that in future.

For the inevitable future messes, wanted to build and test a script to make a 
package obsolete with dummy files, which will replicate the current package dist 
tree with each .hint replicated by replace-versions: ... override.hint and all 
other (tar) files replaced with a zero length minus prefixed basename, uploaded 
and readied by lftp.


I managed to run, test, and clean up, before my ISP connection went flakely.

--
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: Clean out or vault old ncurses test versions

[Brian Inglis via Cygwin-apps]

On 2023-10-21 14:15, Jon Turney via Cygwin-apps wrote:

On 21/10/2023 20:00, Brian Inglis via Cygwin-apps wrote:
Thinking that ncurses i-i.net releases would pause at some point, I have been 
incrementing the release number and appending the date throughout this year, 
but it appears not, so I would now like to reset the primary release number to 
the next after current stable 6.4-3.20230114 and use primary release 
6.4-4.2023 as my test prefix which I would like to make current stable 
some time soon!


I'm quite clear on what this means, but this seems to be a problem of upstream's 
making, if it really is releasing multiple versions called "6.4" (with some 
date/patch level that isn't part of it's version label)


(e.g. look at https://repology.org/project/ncurses/information where there's 
lots of variants on 6.4.x and no way to compare them because individual distros 
make them up in different ways...)


Thanks Jon,

The occasional/annual "official" GNU release is 6.4 but i-i.net seems to package 
a new tarball with a date suffix every few days/weeks, after applying patches 
developed or received.
The package naming pattern seems to be some variation of that with some 
punctuation like ours but more fixed.

I should probably just skip the sequential "release" prefix to the date suffix,
as 6.4-2023 is presumably greater than 6.4-?.2023, and we have not yet 
implemented EPOCH:V-R dating yet, correct?
Is there any way I can blow away my old test releases 6.4-5.2023... thru 
6.4-13.2023... so I can reset the sequence, like listing a bunch of obsoletes 
somehow:

or could someone kind person please do whatever is required if I can not do so?


That said, you can use ssh vault command [1] to expunge versions that are no 
longer required.
(and see the caveat there about how setup won't automatically downgrade from 
removed versions)
If you really care about that, you could then upload appropriate override.hint 
files (note that you need one per subpackage) with a replace-version: line 
indicating the withdrawn version-release(s).
(It's unclear to me if this second step is really worth the effort, given that 
only the presumably small number of people who install ncurses test releases are 
affected.)


...and hopefully they ignore the sequential number.

Just to be clear about the process details and best practice:

I should create a dummy local dist tree for superseded versions,
with the tar file names prefixed with "-" and zero length,
and P-V-R.hint files replaced with override.hint files,
each containing "replace-versions: V-R..." for old versions,
then sftp upload that dist tree in a similar manner to cygport upload?

--
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: Clean out or vault old ncurses test versions

[Brian Inglis via Cygwin-apps]

On 2023-10-21 14:15, Jon Turney via Cygwin-apps wrote:

On 21/10/2023 20:00, Brian Inglis via Cygwin-apps wrote:
On 2023-10-21 11:20, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org 
wrote:
ERROR: 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-4.20231016.tar.xz 
is both uploaded and automatically vaulted
ERROR: 

[..]

SUMMARY: 19 ERROR(s)


So, the reason why this confusing error is being emitted is because you are 
trying to upload a test version 6.4-4.20231016, which is less than the existing 
6.4-12.20230715 and 6.4-13.20230729 test versions.


The default keep-count-test value is 2 (keep the two latest test versions), so 
it would be expired immediately after upload.


This is an error, because that's not something sensible to do, and usually 
indicates a mistake somewhere along the line.


Thinking that ncurses i-i.net releases would pause at some point, I have been 
incrementing the release number and appending the date throughout this year, 
but it appears not, so I would now like to reset the primary release number to 
the next after current stable 6.4-3.20230114 and use primary release 
6.4-4.2023 as my test prefix which I would like to make current stable 
some time soon!


I'm quite clear on what this means, but this seems to be a problem of upstream's 
making, if it really is releasing multiple versions called "6.4" (with some 
date/patch level that isn't part of it's version label)


(e.g. look at https://repology.org/project/ncurses/information where there's 
lots of variants on 6.4.x and no way to compare them because individual distros 
make them up in different ways...)


Is there any way I can blow away my old test releases 6.4-5.2023... thru 
6.4-13.2023... so I can reset the sequence, like listing a bunch of obsoletes 
somehow:


The problem with the concept of "reset the sequence" is that version-release 
identifiers have an ordering.


Anyone who already has these test releases installed, won't (ordinarily) get 
downgraded to a lesser version.



 6.4-5.20230514
 6.4-6.20230520
 6.4-7.20230603
 6.4-8.20230617
 6.4-9.20230625
 6.4-10.20230701
 6.4-11.20230708
 6.4-12.20230715
 6.4-13.20230729

or could someone kind person please do whatever is required if I can not do so?


That said, you can use ssh vault command [1] to expunge versions that are no 
longer required.


(and see the caveat there about how setup won't automatically downgrade from 
removed versions)


If you really care about that, you could then upload appropriate override.hint 
files (note that you need one per subpackage) with a replace-version: line 
indicating the withdrawn version-release(s).


(It's unclear to me if this second step is really worth the effort, given that 
only the presumably small number of people who install ncurses test releases are 
affected.)


[1]  https://cygwin.com/package-upload.html#deleting


Thanks Jon,

I was unaware that useful command had been added.

Finally: you don't need to scrimp and save integers.  I happen to have an 
inexhaustible supply of monotonically increasing ones...


As does ncurses unfortunately; had I known they would be updating almost weekly, 
I would have used the approach I am now going for, rather than the pattern 
established earlier with less frequent updates.


--
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

Clean out or vault old ncurses test versions

[Brian Inglis via Cygwin-apps]

On 2023-10-21 11:20, cygwin-no-re...@cygwin.com wrote:

ERROR: 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-4.20231016.tar.xz is 
both uploaded and automatically vaulted
ERROR: 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-4.20231016.hint is 
both uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4-4.20231016.tar.xz 
is both uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4-4.20231016.hint is 
both uploaded and automatically vaulted
ERROR: 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4-4.20231016.tar.xz is 
both uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4-4.20231016.hint 
is both uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/terminfo/terminfo-6.4-4.20231016.hint is both 
uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/terminfo/terminfo-6.4-4.20231016.tar.xz is both 
uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/ncurses-6.4-4.20231016.hint is both uploaded and 
automatically vaulted
ERROR: x86_64/release/ncurses/ncurses-6.4-4.20231016-src.hint is both uploaded 
and automatically vaulted
ERROR: x86_64/release/ncurses/ncurses-6.4-4.20231016-src.tar.xz is both 
uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/ncurses-6.4-4.20231016.tar.xz is both uploaded 
and automatically vaulted
ERROR: 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4-4.20231016.tar.xz
 is both uploaded and automatically vaulted
ERROR: 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4-4.20231016.hint 
is both uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/libncursesw10/libncursesw10-6.4-4.20231016.hint 
is both uploaded and automatically vaulted
ERROR: x86_64/release/ncurses/libncursesw10/libncursesw10-6.4-4.20231016.tar.xz 
is both uploaded and automatically vaulted
ERROR: 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4-4.20231016.tar.xz 
is both uploaded and automatically vaulted
ERROR: 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4-4.20231016.hint is 
both uploaded and automatically vaulted
ERROR: error while validating movelists for Brian Inglis
SUMMARY: 19 ERROR(s)


Hi folks,

Thinking that ncurses i-i.net releases would pause at some point, I have been 
incrementing the release number and appending the date throughout this year, but 
it appears not, so I would now like to reset the primary release number to the 
next after current stable 6.4-3.20230114 and use primary release 6.4-4.2023 
as my test prefix which I would like to make current stable some time soon!


Is there any way I can blow away my old test releases 6.4-5.2023... thru 
6.4-13.2023... so I can reset the sequence, like listing a bunch of obsoletes 
somehow:


6.4-5.20230514
6.4-6.20230520
6.4-7.20230603
6.4-8.20230617
6.4-9.20230625
6.4-10.20230701
6.4-11.20230708
6.4-12.20230715
6.4-13.20230729

or could someone kind person please do whatever is required if I can not do so?

--
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

tzdata packaging options

[Brian Inglis via Cygwin-apps]

Hi folks,

I have been building and distributing tzdata with maximal backward compatibility 
since adopting the package.


The maintainer and some distros are choosing to consolidate data and drop 
historical details since 1970.
I question whether there are any Cygwin users who use and need the TAI-offset 
including leap seconds zoneinfo/right subtree, and whether we also need to 
include the zoneinfo/posix subtree, duplicating the data in the main zoneinfo tree?


There could be astrologers, genealogists, modern-history historians, and 
developers of related software who use the complete historical details, and 
astronomers, physicists, who use the TAI-offset including leap seconds 
zoneinfo/right subtree.


I am unsure if anyone depends on the posix subtree duplicating the main tree.

I could split the current package into the main tree and the "posix" subtree 
each 1.7MB, and the "right" subtree 2.3MB.


For tzdata-minimal, which could become the Base package, I could generate 
another build with only zones consolidated with common history since 1970, but 
that would require another build with different options to generate the data to 
compile, so presumably another source package, unless there is a way to generate 
say a minimal subtree with another cygmake with different MAKEOPTS, and have it 
packaged the same as the main subtree, or could cygport go bananas?


Fedora was developing a tzdata-minimal package, which was only to include UTC 
for containers, but it looks like  UTC-only should work by not installing *ANY* 
tzdata, so they shelved their efforts:


https://fedoraproject.org/wiki/Changes/tzdata-minimal
https://bugzilla.redhat.com/buglist.cgi?component=tzdata=Fedora

Do we think there could be a use case for a UTC-only (Base?) no tzdata package 
e.g. CI, and the no data defaults will be handled adequately?


For RH see RHEL Timezone Data (tzdata) - Development Status Page:

https://access.redhat.com/articles/1187353

Suggestions for how best to proceed with these options, and to ask these 
questions of users on the main list?


--
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: Updated: mingw64-x86_64-/nghttp2 libnghttp2_14/-devel 1.57

[Brian Inglis via Cygwin-apps]

On 2023-10-14 02:24, Brian Inglis via Cygwin-apps wrote:

On 2023-10-14 00:08, ASSI via Cygwin-apps wrote:

Cygwin nghttp2 Maintainer via Cygwin-announce writes:

* libnghttp2_14    1.57

This library pulls in a lot of build dependencies, but then does not
have any actual dependencies on anything. You seem to be building a
static library? If so, please stop doing that.


As the library is dynamically linked from its utilities, curl and wget2 and 
their libraries, it is obviously not static, it is merely independent and 
self-contained, as with any well designed library!
It would be more helpful if, rather than stating an assumption, and telling me 
to stop (something? - maintaining the package?), you explained why you perceive 
an issue, and how I could detect, diagnose, prevent, and correct the issue you 
perceive.


The /library/ package libnghttp2_14 and cygnghttp2_14.dll do not pull in 
dependencies, but the *utilities* package nghttp2 does, as do its main users 
curl and wget2 and their libraries, and the 140+ packages that use it and/or 
libcurl4; see:


 https://cygwin.com/packages/summary/nghttp2-src.html

 https://cygwin.com/packages/summary/nghttp2.html

 https://cygwin.com/cgit/cygwin-packages/nghttp2/

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=nghttp2

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-nghttp2

and linked commits, updates, patches, and build logs.

Curl and (lib)nghttp2 had high/critical/0day security vulnerabilities disclosed 
and widely publicised this week, requiring immediate attention, and this package 
had Cygwin and Mingw build problems, which I hacked to get them to build, check, 
upload, and announce ASAP.

I have since been working to refactor and rationalize patches to submit 
upstream.
So it is not unreasonable for you or me to suspect there may be issues with 
these "prompt" releases.


If you think there are any issues with this or any of my packages, please 
explain to me any issue you see, and perhaps suggest how to, or a better 
approach to, detect, diagnose, or prevent the issue(s), and to deal with them.
I will put in the effort to learn, and do the work required, to correct and 
improve my approach and results!

[Life should be about doing, learning, improving, and *enjoying* the journey!]


Forgot to attach utilities package binaries post processsed cygcheck log and 
summary.


--
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
Found: /bin/deflatehd.exe
/bin/deflatehd.exe
  /bin/cygnghttp2-14.dll
/bin/cygwin1.dll
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  /bin/cygcrypto-3.dll
/bin/cygz.dll
  /bin/cygjansson-4.dll
  /bin/cyggcc_s-seh-1.dll
  /bin/cygstdc++-6.dll

Found: /bin/h2load.exe
/bin/h2load.exe
  /bin/cygnghttp2-14.dll
/bin/cygwin1.dll
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  /bin/cygcrypto-3.dll
/bin/cygz.dll
  /bin/cygev-4.dll
  /bin/cygssl-3.dll
  /bin/cyggcc_s-seh-1.dll
  /bin/cygstdc++-6.dll

Found: /bin/inflatehd.exe
/bin/inflatehd.exe
  /bin/cygnghttp2-14.dll
/bin/cygwin1.dll
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  /bin/cygcrypto-3.dll
/bin/cygz.dll
  /bin/cygjansson-4.dll
  /bin/cyggcc_s-seh-1.dll
  /bin/cygstdc++-6.dll

Found: /bin/nghttp.exe
/bin/nghttp.exe
  /bin/cygnghttp2-14.dll
/bin/cygwin1.dll
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  /bin/cygcrypto-3.dll
/bin/cygz.dll
  /bin/cygev-4.dll
  /bin/cygjansson-4.dll
  /bin/cygssl-3.dll
  /bin/cygxml2-2.dll
/bin/cygiconv-2.dll
/bin/cyglzma-5.dll
  /bin/cyggcc_s-seh-1.dll
  /bin/cygstdc++-6.dll

Found: /bin/nghttpd.exe
/bin/nghttpd.exe
  /bin/cygnghttp2-14.dll
/bin/cygwin1.dll
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  /bin/cygcrypto-3.dll
/bin/cygz.dll
  /bin/cygev-4.dll
  /bin/cygssl-3.dll
  /bin/cyggcc_s-seh-1.dll
  /bin/cygstdc++-6.dll

Found: /bin/nghttpx.exe
/bin/nghttpx.exe
  /bin/cygnghttp2-14.dll
/bin/cygwin1.dll
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  /bin/cygcares-2.dll
C:\WINDOWS\system32\ADVAPI32.dll
  C:\WINDOWS\system32\msvcrt.dll
  C:\WINDOWS\system32\SECHOST.dll
C:\WINDOWS\system32\RPCRT4.dll
  /bin/cygcrypto-3.dll
/bin/cygz.dll
  /bin/cygev-4.dll
  /bin/cygssl-3.dll
  /bin/cy

Re: Updated: mingw64-x86_64-/nghttp2 libnghttp2_14/-devel 1.57

[Brian Inglis via Cygwin-apps]

On 2023-10-14 00:08, ASSI via Cygwin-apps wrote:

Cygwin nghttp2 Maintainer via Cygwin-announce writes:

* libnghttp2_14 1.57

This library pulls in a lot of build dependencies, but then does not
have any actual dependencies on anything. You seem to be building a
static library? If so, please stop doing that.


As the library is dynamically linked from its utilities, curl and wget2 and 
their libraries, it is obviously not static, it is merely independent and 
self-contained, as with any well designed library!
It would be more helpful if, rather than stating an assumption, and telling me 
to stop (something? - maintaining the package?), you explained why you perceive 
an issue, and how I could detect, diagnose, prevent, and correct the issue you 
perceive.


The /library/ package libnghttp2_14 and cygnghttp2_14.dll do not pull in 
dependencies, but the *utilities* package nghttp2 does, as do its main users 
curl and wget2 and their libraries, and the 140+ packages that use it and/or 
libcurl4; see:


https://cygwin.com/packages/summary/nghttp2-src.html

https://cygwin.com/packages/summary/nghttp2.html

https://cygwin.com/cgit/cygwin-packages/nghttp2/

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=nghttp2

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-nghttp2

and linked commits, updates, patches, and build logs.

Curl and (lib)nghttp2 had high/critical/0day security vulnerabilities disclosed 
and widely publicised this week, requiring immediate attention, and this package 
had Cygwin and Mingw build problems, which I hacked to get them to build, check, 
upload, and announce ASAP.

I have since been working to refactor and rationalize patches to submit 
upstream.
So it is not unreasonable for you or me to suspect there may be issues with 
these "prompt" releases.


If you think there are any issues with this or any of my packages, please 
explain to me any issue you see, and perhaps suggest how to, or a better 
approach to, detect, diagnose, or prevent the issue(s), and to deal with them.
I will put in the effort to learn, and do the work required, to correct and 
improve my approach and results!

[Life should be about doing, learning, improving, and *enjoying* the journey!]

--
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

curl critical vulnerability release Oct 11 Wed 06.00Z

[Brian Inglis via Cygwin-apps]

Hi folks,

Heads up that I will be trying to release an updated curl ASAP after disclosure.
Anything else I or we should consider or announce in advance in these 
circumstances?


--
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: SDL2 2.28.4-1a (Test)

[Brian Inglis via Cygwin-apps]

On 2023-10-06 05:11, Takashi Yano via Cygwin-announce wrote:

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.28.4-1a (Test)
* libSDL2-devel-2.28.4-1a (Test)

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.

- Hopefully, both dinput and xinput work this time.


Should just increment the release unless the upstream uses another qualifier.

--
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