[ITP] python-license-expression and cygport PoC patch (was: calm: SPDX licence list data update please)
On 2024-05-28 08:37, Brian Inglis via Cygwin-apps wrote: 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! I found github/nexB/license-expression Python package to do SPDX licence checks with current data, developed by the same team doing SPDX-toolkit for SPDX, working with Fedora folks et al. Successful attempt to package Python license-expression (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 The package installs and runs using PoC attached in spdx-license-expression.py script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition patch attached. I also ran a test of the Python script and module against all package source cygport files declaring licences which I maintain or ever looked at, including a git/cygwin-packages/*.cygport download from 2023-02, showing the results in the attached log. I also attempted to trap the exceptions in the script, but that does not seem to work in any documented obvious manner, but I do not know enough Python to address this. If someone else who knows python cared to adopt and improve this in a more normal manner, and incorporate this more smoothly into cygport, we could all appreciate that. Alternatively, some candid comments and frank feedback might allow me to do so! ;^> The approach may also be adaptable to calm if you can get python-license-expression 30.3.0 installed on the server(s), and kept updated: https://repology.org/project/python:license-expression/versions and Cygwin should soon be added there hopefully! ;^> -- 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/bin/cygport # python-license-expression.cygport - Python license-expression Cygwin package build control script definitions inherit python-wheel NAME=python-license-expression VERS
Re: newer version of mingw64-*-win-iconv ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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
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
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?
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?
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?
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?
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?
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?
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?
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?
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
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
-- 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
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)
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 .
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)
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
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
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)
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)
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
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
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
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
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
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
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: #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
Re: [cygport] enabling a replacement for "objdump -d -l"
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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)
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
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
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
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
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
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 (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" ] \&\& { _
Re: [ITA] libvpx
On 2023-10-27 09:19, Jon Turney via Cygwin-apps wrote: On 26/10/2023 16:56, Brian Inglis via Cygwin-apps wrote: Hi folks, I have built an updated release of libvpx with the CVE fixes included. This is a Google WebM project which does not use autotools or libtool, so the last maintainer did their own cygvpx dll build and relinked the executables. Taking a brief look over the cygport, if you're going to abstract out the soversion, you can use 'declare' to evaluate variable names e.g. ABI=8 PKG_NAMES="... libvpx${ABI} ..." declare libvpx${ABI}_SUMMARY="$SUMMARY (runtime)" declare libvpx${ABI}_CONTENTS="usr/bin/cygvpx-${ABI}.dll" Thanks Jon, I never realized that, so will now be using it in a number of packages where ABI changes occur. The current test programs do not relink against the unstripped dll, possibly because of their sizes requiring > 32 bit offsets, so I am no longer relinking the test programs with the dll, only the distributed utilities. $ du libvpx-1.13.1-1.x86_64/{build,inst/usr/bin}/*.{dll,exe} 23M libvpx-1.13.1-1.x86_64/build/cygvpx-8.dll 26M libvpx-1.13.1-1.x86_64/build/test_intra_pred_speed.exe 158M libvpx-1.13.1-1.x86_64/build/test_libvpx.exe 33M libvpx-1.13.1-1.x86_64/build/test_rc_interface.exe 3.3M libvpx-1.13.1-1.x86_64/build/vpxdec.exe 3.5M libvpx-1.13.1-1.x86_64/build/vpxenc.exe 3.4M libvpx-1.13.1-1.x86_64/inst/usr/bin/cygvpx-8.dll 680K libvpx-1.13.1-1.x86_64/inst/usr/bin/vpxdec.exe 700K libvpx-1.13.1-1.x86_64/inst/usr/bin/vpxenc.exe With codec performance tests disabled, this build also downloads 1.4GB of test data files from Google under: https://storage.googleapis.com/downloads.webmproject.org/test_data/libvpx/ which we presumably would prefer not to include in the src package, to Yeah, including it seems a bad idea. run tests which take 2.75-3.5 hours out of a 3.75-4.5 hour build, with 5 failures in scallywag CI and 2 failures locally out of 1596 tests, shown in the attached log, so I have questions into the upstream WebM libvpx project about those. Full scallywag logs are available at: https://cygwin.com/cgi-bin2/jobs.cgi?id=7148=libvpx=Brian+Inglis Thanks. I've added this to your packages. Cheers! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
[ITA] libvpx
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 H
Re: Clean out or vault old ncurses test versions
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
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
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
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
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
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
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
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