Re: [PATCH] cygport cygclass/python.org.cygclass pythonhosted archives may require underscores not dashes
[Should we loop in Marco Atzeri here if he does not respond with his €0.02?]
I like the Gentoo design ideas of "PYPI_NO_NORMALIZE=1" "PYPI_PN=..." and
"inherit pypi" to do things the new way?
On 2024-11-06 10:14, Brian Inglis via Cygwin-apps wrote:
On 2024-11-05 13:52, Jon Turney via Cygwin-apps wrote:
On 14/08/2024 08:17, Brian Inglis via Cygwin-apps wrote:
new source packages on pythonhosted appear to change dashes in package
names to underscores in archive names and directories, for example:
python-license-expression ->
license-expression ->
https://files.pythonhosted.org/packages/source/l/license_expression/license_expression-30.3.1.tar.gz
-> license_expression-30.3.1/
although dashes in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license_expression-30.3.1.tar.gz
but dashes work and underscores do not in older package version
archives, although underscores in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license-expression-30.3.0.tar.gz
Thanks for this.
Sorry about the delay in looking at this, but I have been very short of time
recently.
So, first off, I am a bit unhappy about guessing how this supposed to work.
Have PyPI not made any announcement of this change, explaining exactly what it
is?
PEP 625 2020
https://peps.python.org/pep-0625/
normalization:
https://packaging.python.org/en/latest/specifications/binary-distribution-format/
TL;DR: distribution names cannot contain '-' as that is used to delimit version:
"In distribution names, any run of -_. characters (HYPHEN-MINUS, LOW LINE and
FULL STOP) should be replaced with _ (LOW LINE), and uppercase characters should
be replaced with corresponding lowercase ones.
This is equivalent to *regular* name normalization followed by replacing - with
_.
Tools consuming wheels must be prepared to accept . (FULL STOP) and uppercase
letters, however, as these were allowed by an earlier version of this
specification."
as opposed to project ("regular" above) name normalization rules:
https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata
https://packaging.python.org/en/latest/specifications/name-normalization/#name-normalization
So unnormalized names may work, or lowercased, or s/[-._]\+/-/, or s/[-._]\+/_/!
Secondly, I'm not crazy about the "try all the alternatives" approach. Perhaps
it would be better to form the URL using the current (new) rules, with an
escape (e.g. define PYTHON_ORG_OLD_STYLE_URL to form it using the old rules)?
https://warehouse.pypa.io/api-reference/legacy.html#upload-api
"All fields need to be renamed to lowercase and hyphens need to replaced by
underscores.
So instead of “Description-Content-Type” the field must be named
“description_content_type”.
Note that adding a field “Description-Content-Type” will not raise an error but
will be silently ignored."
https://github.com/pypi/warehouse/milestone/12
"Post Legacy Shutdown priorities
Important issues that have gotten unblocked now that legacy PyPI is dead (RIP).
See https://lwn.net/Articles/751458/ for more info."
https://lwn.net/Articles/751458/
Perhaps we should consider the Gentoo eclass changes:
"It should be noted that legacy URLs are no longer supported and may stop
working at an arbitrary time."
like recently:
https://projects.gentoo.org/python/guide/pypi.html
Re: [ITA] aria2 1.37 - HTTP/S, FTP, BitTorrent, Metalink downloader
On 2024-11-05 08:24, Jon Turney via Cygwin-apps wrote: On 28/10/2024 21:38, Brian Inglis via Cygwin-apps wrote: Lightweight, cross platform, multi-protocol, multi-source download utility supports HTTP/S, FTP, BitTorrent, Metalink, and an XML-RPC control interface. For more information see the project home page: https://aria2.github.io/ License: GPL-2.0-or-later AND OpenSSL I would like to adopt and update aria2. Thanks! I added this to your packages. Cheers! For changes since the previous Cygwin release, see below: https://github.com/aria2/aria2/releases Including the whole changelog here and in the announce just makes my eyes glaze over. I think a link is sufficient. Many packages have no linked repo sources, and many distributed ChangeLog, NEWS, RELEASE-NOTES are lengthy and a lot of noise needs edited to summarize updates. For "New" packages, I provide a number of "recent" releases for context versus LTS or WSL Linux releases that some may be using and more familiar with. -- 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] c-ares 1.16.1 - Curl Asynchronous RESolver library
On 2024-11-05 08:24, Jon Turney via Cygwin-apps wrote: On 28/10/2024 21:36, Brian Inglis via Cygwin-apps wrote: Curl Asynchronous RESolver library for applications which need to perform DNS queries without blocking, or need to perform multiple DNS queries in parallel. Primary applications are servers with multiple clients and GUI programs. For more information see the project home page: https://c-ares.org License: MIT I would like to adopt and update c-ares. Thanks. I added this to your packages. Cheers! Attached cygport and at: https://cygwin.com/git/?p=git/cygwin-packages/c-ares.git;f=c- ares.cygport;hb=refs/heads/playground I'm not sure I see the value in including the output of './configure --help' in comments in the cygport. Comparison of previous against latest version config feature options. I will consider where I can run perhaps a script based on: $ diff <(tar -xOf /var/cache/cygport/upstream/coreutils-9.0.tar.xz \ coreutils-9.0/configure | awk -e '/^\s+--(with(out)?|(en|dis)able)-/') <(tar -xOf /var/cache/cygport/upstream/coreutils-9.5.tar.xz \ coreutils-9.5/configure | awk -e '/^\s+--(with(out)?|(en|dis)able)-/') -- 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: [ITP] python-license-expression 30.4 - Python license expression utility library
On 2024-11-05 08:24, Jon Turney via Cygwin-apps wrote: On 28/10/2024 22:08, Brian Inglis via Cygwin-apps wrote: Python comprehensive utility library to parse, compare, simplify and normalize license expressions (such as SPDX license expressions) using boolean logic. For more information see the project home pages: https://github.com/nexB/license-expression https://pypi.org/project/license-expression License: Apache-2.0 I would like to provide a Cygwin package for license-expression Python package to do SPDX licence checks, developed by the same team doing SPDX-toolkit for SPDX, using the same current data, by and working with Fedora folks et al. It is in PyPI and packaged by major Linux and BSD distros, and Msys2: https://repology.org/project/python:license-expression/versions Thanks. Sorry about missing the previous iteration of this. I've added this to your packages. No worries. 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: [PATCH] cygport cygclass/python.org.cygclass pythonhosted archives may require underscores not dashes
On 2024-11-05 13:52, Jon Turney via Cygwin-apps wrote:
On 14/08/2024 08:17, Brian Inglis via Cygwin-apps wrote:
new source packages on pythonhosted appear to change dashes in package
names to underscores in archive names and directories, for example:
python-license-expression ->
license-expression ->
https://files.pythonhosted.org/packages/source/l/license_expression/license_expression-30.3.1.tar.gz
-> license_expression-30.3.1/
although dashes in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license_expression-30.3.1.tar.gz
but dashes work and underscores do not in older package version
archives, although underscores in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license-expression-30.3.0.tar.gz
Thanks for this.
Sorry about the delay in looking at this, but I have been very short of time
recently.
So, first off, I am a bit unhappy about guessing how this supposed to work. Have
PyPI not made any announcement of this change, explaining exactly what it is?
PEP 625 2020
https://peps.python.org/pep-0625/
normalization:
https://packaging.python.org/en/latest/specifications/binary-distribution-format/
TL;DR: distribution names cannot contain '-' as that is used to delimit version:
"In distribution names, any run of -_. characters (HYPHEN-MINUS, LOW LINE and
FULL STOP) should be replaced with _ (LOW LINE), and uppercase characters should
be replaced with corresponding lowercase ones.
This is equivalent to *regular* name normalization followed by replacing - with
_.
Tools consuming wheels must be prepared to accept . (FULL STOP) and uppercase
letters, however, as these were allowed by an earlier version of this
specification."
as opposed to project ("regular" above) name normalization rules:
https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata
https://packaging.python.org/en/latest/specifications/name-normalization/#name-normalization
So unnormalized names may work, or lowercased, or s/[-._]\+/-/, or s/[-._]\+/_/!
Secondly, I'm not crazy about the "try all the alternatives" approach. Perhaps
it would be better to form the URL using the current (new) rules, with an escape
(e.g. define PYTHON_ORG_OLD_STYLE_URL to form it using the old rules)?
https://warehouse.pypa.io/api-reference/legacy.html#upload-api
"All fields need to be renamed to lowercase and hyphens need to replaced by
underscores.
So instead of “Description-Content-Type” the field must be named
“description_content_type”.
Note that adding a field “Description-Content-Type” will not raise an error but
will be silently ignored."
https://github.com/pypi/warehouse/milestone/12
"Post Legacy Shutdown priorities
Important issues that have gotten unblocked now that legacy PyPI is dead (RIP).
See https://lwn.net/Articles/751458/ for more info."
https://lwn.net/Articles/751458/
Perhaps we should consider the Gentoo eclass changes:
"It should be noted that legacy URLs are no longer supported and may stop
working at an arbitrary time."
like recently:
https://projects.gentoo.org/python/guide/pypi.html
--
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
[ITP] python-license-expression 30.4 - Python license expression utility library
Python comprehensive utility library to parse, compare, simplify
and normalize license expressions (such as SPDX license expressions)
using boolean logic.
For more information see the project home pages:
https://github.com/nexB/license-expression
https://pypi.org/project/license-expression
License:Apache-2.0
I would like to provide a Cygwin package for license-expression Python
package to do SPDX licence checks, developed by the same team doing
SPDX-toolkit for SPDX, using the same current data, by and working with
Fedora folks et al.
It is in PyPI and packaged by major Linux and BSD distros, and Msys2:
https://repology.org/project/python:license-expression/versions
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/playground/tree/python-license-expression.cygport?h=playground
package job fails as files.pythonhosted.org recent package
directory paths now require "_" instead of "-"!
https://cygwin.com/cgi-bin2/jobs.cgi?id=8987&srcpkg=playground&user=Brian+Inglis
log at:
https://github.com/cygwin/scallywag/actions/runs/11517043356/job/32060933142
which could be fixed by the python.org cygclass patch attached.
The package has been installed and running on my system for many weeks using
the PoC script attached in spdx-license-expression.py hooked into
/usr/share/cygport/lib/pkg_pkg.cygpart by the license hint addition
patch attached.
I also reran 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.
Recent changes:
2024-10-21 30.4
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.25
- Drop support for Python 3.8
2024-08-13 30.3.1
- Update link references of ownership from nexB to aboutcode-org
2024-03-18 30.3
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.23
- Drop support for Python 3.7
2023-11-29 30.2
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.22
- Add Python 3.12 support in CI
2023-01-16 30.1.1
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.20
2023-01-16 30.1
- Use latest skeleton (and updated configure script)
- Update license list to latest ScanCode and SPDX 3.19
- Use correct syntax for python_require
- Drop using Travis and Appveyor
- Drop support for Python 3.7 and add Python 3.11 in CI
2022-05-10 30.0
This is a minor release with API changes
- Use latest skeleton (and updated configure script)
- Drop using calver
- Improve error checking when combining licenses
#|/usr/bin/cygport
# python-license-expression.cygport - Python license-expression Cygwin package
build control script definitions
inherit python3-wheel
NAME=python-license-expression
VERSION=30.4.0
RELEASE=1
BASE=${NAME#python-}
CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python comprehensive utility library to parse, compare, simplify
and normalize license expressions (such as SPDX license expressions)
using boolean logic."
ARCH=noarch
LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"
DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"
From 9c39a99af74e597d71b5fde490b4bdf384db634d Mon Sep 17 00:00:00 2001
Message-ID:
<9c39a99af74e597d71b5fde490b4bdf384db634d.1723619679.git.brian.ing...@systematicsw.ab.ca>
From: Brian Inglis
Bcc: Brian Inglis
To: Cygwin Apps
Date: Wed, 14 Aug 2024 01:14:28 -0600
Subject: [PATCH] cygport cygclass/python.org.cygclass pythonhosted archives may
require underscores not dashes
Organization: Systematic Software
new source packages on pythonhosted appear to change dashes in package
names to underscores in archive names and directories, for example:
python-license-expression ->
license-expression ->
https://files.pythonhosted.org/packages/source/l/license_expression/license_expression-30.3.1.tar.gz
-> license_expression-30.3.1/
although dashes in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license_expression-30.3.1.tar.gz
but dashes work and underscores do not in older package version
archives, although underscores in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license-expression-30.3.0.tar.gz
so keep pythonhosted package directory names verbatim and iterate setting
SRC_DIR to package name verbatim or underscored and test availability with:
wget -q --spider ...
or
curl --silent --fail -o /dev/null 2> /dev/null ...
Signed-off-by: Brian Inglis
---
cygclass/python.org.cygclass | 6 +-
1 file changed, 5 insertions(+
[ITA] aria2 1.37 - HTTP/S, FTP, BitTorrent, Metalink downloader
Lightweight, cross platform, multi-protocol, multi-source download utility supports HTTP/S, FTP, BitTorrent, Metalink, and an XML-RPC control interface. For more information see the project home page: https://aria2.github.io/ License:GPL-2.0-or-later AND OpenSSL I would like to adopt and update aria2. Attached cygport and at: https://cygwin.com/git/?p=git/cygwin-packages/aria2.git;f=aria2.cygport;hb=refs/heads/playground package job: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=aria2 log at: https://github.com/cygwin/scallywag/actions/runs/11557714331/job/32168615991 I am running the updated package in place of current with no obvious issues, and raised an issue upstream about the test failure. For changes since the previous Cygwin release, see below: https://github.com/aria2/aria2/releases 2023-11-15 1.37 - Fix header in --http-accept-gzip documentation - Fix typo in documentation, --help text - Update aria2c.rst - Allow empty dist name in bencode which is needed for hybrid torrent - Better entropy for getRandomBytes - Deal with missing nproc on macos - Bump actions - Bump workflow ubuntu - Add missing include to WinTLSSession.h - Fix undefined behavior/crash in GZipEncoder - Fix Metalink4 parsing with foreign namespaces - fix wrong dht.dat binary file structure in docs - Increase ByteArrayDiskWriter maximum size - Minor grammar improvements - Fix static link failure against libssh2 - Update Dockerfile.mingw - Prefer random number generator from crypto libraries - android(ndk r23) has timegm - Add Dockerfile.android - Remove deprecated std::unary_function and std::binary_function - Update wslay - Fix test errors with ubsan - ci: Build with gnutls - ci: Build mingw image - Revert "ci: Build mingw image" - Fix overflow - Make releases with docker - Dockerfile.mingw: Parallel build - Dockerfile.android: Add dpkg-dev for dpkg-architecture - Dockerfile.mingw: Remove deprecated libssh2 configure flags - Dockerfile.mingw: Update how to get aria2c.exe from a container - Update sphinx_rtd_theme - Static check fix - Do not close stdout and stderr - Avoid non-nil argument errors - Logger: Fix format string overflow in writeHeader() - ci: Bump gcc and clang - Do not require strict C++ mode and update ax_cxx_compile_stdcxx.m4 - Cap infoHashLength in .aria2 file - Fix non bt build error - Various documenation fixes and rewords - Change 'meta data' to 'metadata' - Dockerfile: Bump c-ares to 1.21.0 - Dockerfile.mingw: Downgrade c-ares to 1.19.1 2021-08-21 1.36 - Update wslay - Bump Windows build dependencies - Bump android build dependencies - Fix segfault when time_t is 64bit on 32bit arch - Updates the make_bash_completion script to Python3. - Prevent corrupt downloads after app and/or system crash - Reset sessionDownloadLength and sessionUploadLength on download start - AppleTLS: Add TLSv1.3 support 2019-10-06 1.35 - Update mingw build dependencies - Update android build dependencies Update android build dependencies. Use android NDK r20 and build aarch64 binary. - Drop SSLv3.0 and TLSv1.0 and add TLSv1.3 support for GNUTLS and OpenSSL. - Platform: Fix compilation without deprecated OpenSSL APIs - Remove linux getrandom and use C++ stdlib instead - Don't send Accept Metalink header if Metalink is disabled - gnutls: Fix bug that commonName is always empty - Fix openssl API version logic for libressl 2.7.x - Fix build failure when InternalDHKeyExchange is used 2018-05-15 1.34 - mingw: Use SetFileTime to avoid DST adjustment - UnknownLengthPieceStorage: return piece length to show something in console status when downloading items with unknown content length - WinConsoleFile: fix colour properly - util: also detect XDG_* env variables on Windows - MacOS: Allocate once (apfs compat) - Fix bug that signal handler does not work with libaria2 when aria2::RUN_ONCE is passed to aria2::run() - Retry on HTTP 502 2017-11-08 1.33.1 - mingw: Fix high CPU usage in BitTorrent downloads 2017-10-17 1.33.0 - Include arm in a filename of android zip - Upgrade base image of Dockerfile.mingw to ubuntu:16.04 - wintls: Potential fix for undecrypted read - libaria2: Return last error code from DownloadHandle::getErrorCode - Windows: pass writefds also as exceptfds to select() winsock notifies connect() failures on exceptfds instead of writefds. - libuv: use pkg-config - FeatureConfig: align text - Update Dockerfile.mingw avoid docker cache when using git - Add --peer-agent option for setting the version/user agent used in the extended handshake protocol for bittorrent. - OSX: Allow to specify a build - OSX: update c-ares - [Docs, libaria2] Fix type of obj pushed into options vector aria::KeyVals is a vector of pair of std strings, therefore the type of object being pushed should be std::pair, however in the docs, the type of the said object is KeyVals. If one follows the docs, code will fail to compile. - AppleTLS: Silence cipher suite se
[ITA] c-ares 1.16.1 - Curl Asynchronous RESolver library
Curl Asynchronous RESolver library for applications which
need to perform DNS queries without blocking, or
need to perform multiple DNS queries in parallel.
Primary applications are servers with multiple clients and GUI programs.
For more information see the project home page:
https://c-ares.org
License:MIT
I would like to adopt and update c-ares.
Attached cygport and at:
https://cygwin.com/git/?p=git/cygwin-packages/c-ares.git;f=c-ares.cygport;hb=refs/heads/playground
package job:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=c-ares
log at:
https://github.com/cygwin/scallywag/actions/runs/11544066103/job/32129211570
I am running and building with the updated package in place of current
with no obvious issues, and would like to make this updated release
current for building with other packages, before trying to update to the
latest release which has build issues.
For changes since the previous Cygwin release, see below:
https://c-ares.org/changelog.html#c-ares-version-1161---may-11-2020
2020-05-11 1.16.1
Security:
- Prevent possible use-after-free and double-free in
ares_getaddrinfo() if ares_destroy() is called prior to
ares_getaddrinfo() completing.
Changes:
- Allow TXT records on CHAOS qclass. Used for retriving things like
version.bind, version.server, authoris.bind, hostname.bind, and
id.server.
Bug fixes:
- Fix Windows Unicode incompatibilities with ares_getaddrinfo()
- Silence false cast-align compiler warnings due to valid casts of
struct sockaddr to struct sockaddr_in and struct sockaddr_in6.
- MacOS should use libresolv for retrieving DNS servers, like iOS
- CMake build system should populate the INCLUDE_DIRECTORIES property
of installed targets
- Correct macros in use for the ares_getaddrinfo.3 man page
2020-03-13 1.16.0
Changes:
- Introduction of ares_getaddrinfo() API which provides similar output
(including proper sorting as per RFC 6724) to the system native API,
but utilizes different data structures in order to provide additional
information such as TTLs and all aliases.
Please reference the respective man pages for usage details.
- Parse SOA records from ns_t_any response
- CMake: Provide c-ares version in package export file
- CMake: Add CPACK functionality for DEB and RPM
- CMake: Generate PDB files during build
- CMake: Support manpage installation
Bug fixes:
- Fix bad expectation in IPv6 localhost test.
- AutoTools: use XC_CHECK_BUILD_FLAGS instead of XC_CHECK_USER_FLAGS to
prevent complaints about CPPFLAGS in CFLAGS.
- Fix .onion handling
- Command line usage was out of date for adig and ahost.
- Typos in manpages
- If ares_getenv is defined, it must return a value on all platforms
- If /etc/resolv.conf has invalid lookup values, use the defaults.
- Tests: Separate live tests from SetServers* tests as only live tests
should require internet access.
- ares_gethostbyname() should return ENODATA if no valid A or
record is found, but a CNAME was found.
- CMake: Rework library function checking to prevent unintended linking
with system libraries that aren’t needed.
- Due to use of inet_addr() it was not possible to return
255.255.255.255 from ares_gethostbyname().
- CMake: Fix building of tests on Windows
2018-10-23 1.15.0
Changes:
- Add ares_init_options() configurability for path to resolv.conf file
- Ability to exclude building of tools (adig, ahost, acountry) in CMake
- Android: Support for domain search suffix
- Report ARES_ENOTFOUND for .onion domain names as per RFC7686
Bug fixes:
- AIX build fix for trying to include both nameser_compat.h and
onameser_compat.h
- Windows: Improve DNS suffixes extracting from WinNT registry
- Fix modern GCC warnings
- Apply the IPv6 server blacklist to all nameserver sources, not just
Windows
- Fix warnings emitted by MSVC when using -W4
- Prevent changing name servers while queries are outstanding
- Harden and rationalize c-ares timeout computation
- Distribute ares_android.h
- ares_set_servers_csv() on failure should not leave channel in a bad
state
- Add missing docs to distribution
#|/usr/bin/cygport
# c-ares.cygport - c-ares Cygwin package build control script definitions
NAME=c-ares
VERSION=1.16.1
RELEASE=1
CATEGORY="Net Libs"
SUMMARY="Curl Asynchronous RESolver library"
DESCRIPTION="Curl Asynchronous RESolver library for applications which
need to perform DNS queries without blocking, or
need to perform multiple DNS queries in parallel.
Primary applications are servers with multiple clients and GUI programs."
HOMEPAGE=https://$NAME.haxx.se/
SRC_URI=$HOMEPAGE/download/$NAME-$VERSION.tar.gz
HOMEPAGE=https://$NAME.org/
dir=$NAME/releases/download/${NAME/-}-${VERSION//./_}
SRC_URI=https://github.com/$NAME/$dir/$NAME-$VERSION.tar.gz
SRC_URI+=" $SRC_URI.asc"
PATCH_URI=
#FEDORA=https://src.fedoraproject.org/rpms/$NAME/raw/f29/f
# $FEDORA/0001-Use-RPM-compiler-options.patch
# 1.13.0-cygwin.patch
#FEDORA=http://pkgs.fedoraproject
Re: Japanese translation res.rc patch
Ya Takeda-san, You may wish to consider installing Cygwin package po4a https://po4a.org/ which does the same job under Cygwin. See https://po4a.org/man/ or after installation read po4a(7) and po4a(1p): msguntypot (1p) - update PO files when a typo is fixed in POT file po4a (1p)- update both the PO files and translated documents in one shot po4a (7) - framework to translate documentation and other materials po4a-display-man (1) - display a translated man page according to a PO po4a-display-pod (1) - display of a translated POD file according to a PO po4a-gettextize (1p) - convert an original file (and its translation) to a PO file po4a-normalize (1p) - normalize a documentation file by parsing it in po4a, and writing it back po4a-translate (1p) - convert a PO file back to documentation format po4a-updatepo (1p) - update the translation (in PO format) of documentation [Don't forget the blank space after '-- ' in your signature to allow stripping.] Best wishes. On 2024-10-26 22:33, 武田洋幸 via Cygwin-apps wrote: Sorry for the late submission. This is a patch from the latest repository. I also wanted to create the po/ja/res/po files, so I installed the Translate Toolkit on Ubuntu in WSL, but I didn't know how to use rc2po. I didn't know what a templete file was. Could you explain it briefly plese? 2024年10月22日(火) 16:36 武田洋幸 : Sorry. At first, I thought that the 8pt MS Dlg resource font was too small in the Japanese environment, so I just changed it in res.rc and translated it. I realized about the po file and the weblate project after I had finished the work. I wrote a program in PHP to extract strings from res.rc, copied and pasted it into Google Translate, translated it, and finally searched res.rc with the original text as a key and replaced it with the translation. I later found out that I should prepare the Japanese po file myself. Thank you for your work. I did this in a few hours (because it was copy and paste work), but it seems like it would be a pain to use the mouse when working with weblate. This time, I used a spreadsheet because I wanted the original text and the translation to match line by line in TSV. I also knew about a software called poEdit that can be linked to the Google Translate API, but I worked on it on impulse this time, so I'm sorry... I will follow the rules from next time. I also have some slightly revised resources that I will send to you within 24 hours. 2024年10月21日(月) 2:51 Jon Turney : On 16/10/2024 20:59, 武田洋幸 via Cygwin-apps wrote: Hi, I created a Japanese translation of Cygwin Setup using res/ja/res.rc without using Weblate. Thanks. I applied this. I was assuming you'd made a translation of the pot template in a local po file, and then generated the resource file, but it seems not. We should probably have some instructions on how that all works added to the README, but the idea is that, to avoid having to make coordinated changes in lots of translated resource files if we ever add/remove/move a control etc., the translation are stored in po files, and the 'po2rc' tool [1] is used to generate translated resource files, using the English resource file as a template. Anyhow, I used the reverse process to extract your translation to a po file, so this process can be used to generate the ja translated resource file in future. (I did a brief review to see if you'd made any adjustments to the dialog layouts to accommodate the size of the translated strings, but didn't find any. If there are any, can you make me aware of those, so we can adjust the template appropriately) I generated a test build, which can be found at: https://cygwin.com/setup/setup-2.932-28-gbbcd1d.x86_64.exe Please let know if there are any problems with that. Thanks again. [1] https://github.com/translate/translate -- 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 CI pythonhosted archive downloads failing 404 Not Found
Hi folks,
Scallywag CI pythonhosted archive downloads are failing with 404 Not Found due
to directory names needing underscores not dashes!
See below for details.
On 2024-08-14 01:17, Brian Inglis via Cygwin-apps wrote:
new source packages on pythonhosted appear to change dashes in package
names to underscores in archive names and directories, for example:
python-license-expression ->
license-expression ->
https://files.pythonhosted.org/packages/source/l/license_expression/license_expression-30.3.1.tar.gz
-> license_expression-30.3.1/
although dashes in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license_expression-30.3.1.tar.gz
but dashes work and underscores do not in older package version
archives, although underscores in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license-expression-30.3.0.tar.gz
so keep pythonhosted package directory names verbatim and iterate setting
SRC_DIR to package name verbatim or underscored and test availability with:
wget -q --spider ...
or
curl --silent --fail -o /dev/null 2> /dev/null ...
Signed-off-by: Brian Inglis
---
cygclass/python.org.cygclass | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cygclass/python.org.cygclass b/cygclass/python.org.cygclass
index 51434ba6c08f..a1b8fb89ec73 100644
--- a/cygclass/python.org.cygclass
+++ b/cygclass/python.org.cygclass
@@ -50,4 +50,8 @@ HOMEPAGE="https://pypi.org/project/${PYTHON_ORG_NAME}";
# DESCRIPTION
# Download location of the Python module on the Python Package Index.
#
-SRC_URI="https://files.pythonhosted.org/packages/source/${PYTHON_ORG_NAME:0:1}/${PYTHON_ORG_NAME}/${PYTHON_ORG_NAME}-${PV}.tar.gz";
+for SRC_DIR in ${PYTHON_ORG_NAME}-${PV} ${PYTHON_ORG_NAME//-/_}-${PV}
+do
+
SRC_URI=https://files.pythonhosted.org/packages/source/${PYTHON_ORG_NAME:0:1}/${PYTHON_ORG_NAME}/${SRC_DIR}.tar.gz
+wget --quiet --spider $SRC_URI && break
+done
--
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
Python PEP 517 pyproject.toml/PKG-INFO build support
Hi folks, Is any Pythonista considering how to add Python PEP 517 pyproject.toml/build-backend/PKG-INFO build support? Current python builds are getting noisier and pickier about how things should be done using standard approaches: - that deprecated approaches and modules are being used, - running setup.py instead of setuptools.build_meta:__legacy__, - running installer and using eggs, - lack of package data, - with links to articles about deprecated practices, and docs on preferred standard practices, - configure scripts to download and set up virtual environment tools, without which tests don't start! -- 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] m4/libtool.m4: fix test when multilib not used by project
Hi folks, Latest libtool has a bug when config tests ld - patch submitted upstream - dups recent bug report and patch. Libtool maintainer may wish to apply to current package in new release for package maintainers. -- 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--- Begin Message --- test and config fails when projects do not use multilib add usual x prefix to both sides to protect multilib test Fixes: ab89ebbcc2ff0ecff5157982ef03627cfd615f7e --- a/m4/libtool.m4 2024-10-03 06:50:08.0 -0600 +++ b/m4/libtool.m4 2024-10-19 14:09:21.384266500 -0600 @@ -2569,7 +2569,7 @@ cygwin* | mingw* | windows* | pw32* | ce # If user builds GCC with mulitlibs enabled, # it should just install on $(libdir) # not on $(libdir)/../bin or 32 bits dlls would override 64 bit ones. -if test yes = $multilib; then +if test xyes = x$multilib; then postinstall_cmds='base_file=`basename \$file`~ dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\$base_file'\''i; echo \$dlname'\''`~ dldir=$destdir/`dirname \$dlpath`~ --- End Message ---
Re: Japanese translation res.rc patch
On 2024-10-20 11:51, Jon Turney via Cygwin-apps wrote: On 16/10/2024 20:59, 武田洋幸 via Cygwin-apps wrote: Hi, I created a Japanese translation of Cygwin Setup using res/ja/res.rc without using Weblate. Thanks. I applied this. I was assuming you'd made a translation of the pot template in a local po file, and then generated the resource file, but it seems not. We should probably have some instructions on how that all works added to the README, but the idea is that, to avoid having to make coordinated changes in lots of translated resource files if we ever add/remove/move a control etc., the translation are stored in po files, and the 'po2rc' tool [1] is used to generate translated resource files, using the English resource file as a template. Anyhow, I used the reverse process to extract your translation to a po file, so this process can be used to generate the ja translated resource file in future. A link to the regenerated rc may be useful for review and responses: https://cygwin.com/git/?p=cygwin-apps/setup.git;a=commitdiff;h=bbcd1d37e8114fd825cc657cd416c29a5aa40de8 (I did a brief review to see if you'd made any adjustments to the dialog layouts to accommodate the size of the translated strings, but didn't find any. If there are any, can you make me aware of those, so we can adjust the template appropriately) I generated a test build, which can be found at: https://cygwin.com/setup/setup-2.932-28-gbbcd1d.x86_64.exe Please let know if there are any problems with that. Thanks again. [1] https://github.com/translate/translate -- 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: Fw: found aclocal
[Sorry autocompleted wrong list] On 2024-10-10 15:01, Brian Inglis via Cygwin-apps wrote: On 2024-10-10 02:49, Jim McNamara wrote: deathly slow oops. On Thursday, October 10th, 2024 at 4:47 AM, Jim McNamara wrote: I found aclocal. It was named aclocal-1.16 or some such. I tried searching find / -name 'aclocal*' and it is deafly slow. I tried in windows explorer and it came up fast. I need to fix locate on this machine if i can do a wild card search or just use explorer for quicker searches. Use bash: $ ll /*bin/aclocal* you can also search subdirs with .../**/... Don't worry about the bits - just install Cygwin packages autoconf, automake, autogen, gcc-core, make and on Cygwin run from the source directory: $ autoreconf -fiv $ ./configure $ make although often an out of tree build is preferred to separate generated output from source input, but there are quirks that cygport works around or allows you to handle easily. -- 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: Fw: found aclocal
On 2024-10-10 02:49, Jim McNamara wrote: deathly slow oops. On Thursday, October 10th, 2024 at 4:47 AM, Jim McNamara wrote: I found aclocal. It was named aclocal-1.16 or some such. I tried searching find / -name 'aclocal*' and it is deafly slow. I tried in windows explorer and it came up fast. I need to fix locate on this machine if i can do a wild card search or just use explorer for quicker searches. Use bash: $ ll /*bin/aclocal* you can also search subdirs with .../**/... Don't worry about the bits - just install Cygwin packages autoconf, automake, autogen, gcc-core, make and on Cygwin run from the source directory: $ autoreconf -fiv $ ./configure $ make although often an out of tree build is preferred to separate generated output from source input, but there are quirks that cygport works around or allows you to handle easily. -- 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] ca-certificates-letsencrypt maintainer
On 2024-07-14 19:40, Brian Inglis via Cygwin-apps wrote: On 2024-07-14 13:46, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: Re-installed last ca-certificates-letencrypt package and cygport announce and git send-email are working again. Then keep it installed one or two months longer, but I will not revive that package. The original problem with the R3 cross-signed through X3 went away at least a year ago already and the last R3 signed certificates (that don't have this problem) should expire somewhere in the next two or three months latest. New certificates should be signed by R10 or R11 already. Sorry Achim, But given that the Cygwin certs appear that they may require some of these, and does not expire until mid-August, might it not have been better to keep the package around until after then? Some unexpired letsencrypt certificates should probably have been migrated to ca-certificates or left in ca-certificates-letencrypt? Nope. so were any DigiCert certs harmed in the making of this package? ;^> Bollocks. If installing ca-certificates-letencrypt fixes it for you, then it's either an old TrustID X3 or Let's Encrypt R3 certificate (probably the latter) somewhere in the cert chain _plus_ an openssl earlier than 1.2 (as these had a bug in cert validation that gets triggered during validation of a cross-signed a CA). I do not know how to figure out what is in these cert packages, and what correlation is significant between those, my email server, cygwin/sourceware email server, cygport pkg_upload(__pkg_announce) and git send-email. Anyway, the current openssl has no problems with either of the servers you mentioned: It seems to me that both /usr/share/cygport/lib/pkg_upload.cygpart __pkg_announce() and /usr/libexec/git-core/git-send-email send_message() have Net::SMTP::SSL in common: those perl modules and dependencies all seem to be 5.36, and I have no idea how they link to OpenSSL, but could they eventually link to the old OpenSSL 1.1.1w, and could that be causing an issue? It seems with the latest ca-certificates obsoleting ca-certificates-letsencrypt, and possibly other Perl package updates, that I can now email here and elsewhere using cygport, git-email, and other Cygwin packages, without any issues. -- 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
test email provider certs
From: brian.ing...@systematicsw.ab.ca test email provider certs
Re: fontconfig cache missing TeX fonts and non-MS Windows fonts
On 2024-09-21 14:49, Ken Brown via Cygwin-apps wrote:
On 9/20/2024 11:43 PM, Brian Inglis via Cygwin-apps wrote:
On 2024-09-20 15:44, Brian Inglis via Cygwin-apps wrote:
Hi folks,
I recently reviewed all the fonts installed on my system and found that
fontconfig cache does not include TeX OpenType or TrueType fonts installed
under /usr/share/texmf-dist/fonts/{open,true}type/, non-'Microsoft Corp'
Windows fonts including those labelled 'Microsoft supplied font', .TTF, .ttc,
and .ot[cf], but does cache those in the Windows/Fonts/Deleted subdirectory.
For the fonts that come with TeX Live, I thought it should be up to the user
whether or not to include those fonts in the fontconfig cache. The admittedly
very long release message for TeX Live says the following near the end:
"There is a script /usr/bin/texlive-enable-fontconfig that you can
run if you want the fonts distributed with TeX Live to be available
to applications that rely on fontconfig. See /usr/share/doc/texlive/
README.Cygwin for more details."
I remember discussing this on the list at some point, and the consensus at the
time was that this should not be done by default, but I don't remember the
reason(s). We could revisit this decision if enough people have strong feelings
about it. If so, I think the discussion should be on the main Cygwin list so
that non-maintainers can weigh in.
Thanks Ken,
I missed that in the announcement and will use that from now on, as for me
TeXlive etc. are mainly prereqs for package builds.
I come from a scary place where I was updating hourly stats and graphs and
generating 100k+ fontconfig cache files taking many GB, so I preferred to blow
away the cache directory and repopulate every setup run, and sometimes between
runs when a cron job detected insanity was happening.
That era now appears to be in the past with fontconfig cache fixes. X-fingers!
I also frequently poke around font files looking for glyphs, ranges, etc.
So I like having all available fonts in my cache.
Is there any consensus on how this should be managed?
I would think Unix systems would want all installed fonts cached.
I would also think all Cygwin users would probably like to be able to use all
their Windows fonts, not just 'MS Corp' copyright .ttf and optionally TeX, in
their Cygwin packages?
I agree it may be a good question to ask on the main list.
If few care enough to respond, the status quo stands!
--
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: fontconfig cache missing TeX fonts and non-MS Windows fonts
On 2024-09-20 15:44, Brian Inglis via Cygwin-apps wrote:
Hi folks,
I recently reviewed all the fonts installed on my system and found that
fontconfig cache does not include TeX OpenType or TrueType fonts installed under
/usr/share/texmf-dist/fonts/{open,true}type/, non-'Microsoft Corp' Windows fonts
including those labelled 'Microsoft supplied font', .TTF, .ttc, and .ot[cf], but
does cache those in the Windows/Fonts/Deleted subdirectory.
I run the attached permanent postinstall local script to pick up all those fonts
the official script does not, clean up old broken links, link the font files
into /usr/share/fonts/windows/ and /usr/share/fonts/{open,true}type/texmf-dist/
as appropriate, then mkfontscale fonts.scale and mkfontdir fonts.dir in each.
Please consider changing the official current stable permanent postinstall
script to include these font installation directories, plus any others that
maintainers may be aware of outside /usr/share/fonts/.
These would include fonts in Octave, Python, Ruby package directories: not all
in /usr/share/fonts/ or my texmf-dist links, and those are may be duplicated
>>> typo and those that are duplicated may be
from actual font packages, so would the best approach for these require the font
packages, provide a standard location font subpackage linked to the package
directory, or suggestions?
/usr/lib/python2.7/site-packages/reportlab/fonts/
/usr/lib/python2.7/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python2.7/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python2.7/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.6/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.6/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.6/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.7/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.7/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.7/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.8/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.8/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.8/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.9/site-packages/matplotlib/mpl-data/fonts/ttf/
/usr/lib/python3.9/site-packages/reportlab/fonts/
/usr/lib/python3.9/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.9/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.9/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/share/gems/doc/activesupport-5.1.6/rdoc/fonts/
/usr/share/gems/doc/coffee-rails-4.2.2/rdoc/fonts/
/usr/share/gems/doc/coffee-script-2.4.1/rdoc/fonts/
/usr/share/gems/doc/coffee-script-source-1.10.0/rdoc/fonts/
/usr/share/gems/doc/erubis-2.7.0/rdoc/fonts/
/usr/share/gems/doc/execjs-2.5.2/rdoc/fonts/
/usr/share/gems/doc/sass-3.5.6/rdoc/fonts/
/usr/share/gems/doc/uglifier-3.1.13/rdoc/fonts/
/usr/share/gems/gems/rdoc-6.7.0/lib/rdoc/generator/template/darkfish/fonts/
/usr/share/octave/8.4.0/fonts/
--
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
fontconfig cache missing TeX fonts and non-MS Windows fonts
Hi folks,
I recently reviewed all the fonts installed on my system and found that
fontconfig cache does not include TeX OpenType or TrueType fonts installed under
/usr/share/texmf-dist/fonts/{open,true}type/, non-'Microsoft Corp' Windows fonts
including those labelled 'Microsoft supplied font', .TTF, .ttc, and .ot[cf], but
does cache those in the Windows/Fonts/Deleted subdirectory.
I run the attached permanent postinstall local script to pick up all those fonts
the official script does not, clean up old broken links, link the font files
into /usr/share/fonts/windows/ and /usr/share/fonts/{open,true}type/texmf-dist/
as appropriate, then mkfontscale fonts.scale and mkfontdir fonts.dir in each.
Please consider changing the official current stable permanent postinstall
script to include these font installation directories, plus any others that
maintainers may be aware of outside /usr/share/fonts/.
These would include fonts in Octave, Python, Ruby package directories: not all
in /usr/share/fonts/ or my texmf-dist links, and those are may be duplicated
from actual font packages, so would the best approach for these require the font
packages, provide a standard location font subpackage linked to the package
directory, or suggestions?
/usr/lib/python2.7/site-packages/reportlab/fonts/
/usr/lib/python2.7/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python2.7/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python2.7/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.6/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.6/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.6/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.7/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.7/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.7/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.8/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.8/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.8/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/lib/python3.9/site-packages/matplotlib/mpl-data/fonts/ttf/
/usr/lib/python3.9/site-packages/reportlab/fonts/
/usr/lib/python3.9/site-packages/sphinx_rtd_theme/static/fonts/
/usr/lib/python3.9/site-packages/sphinx_rtd_theme/static/fonts/Lato/
/usr/lib/python3.9/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab/
/usr/share/gems/doc/activesupport-5.1.6/rdoc/fonts/
/usr/share/gems/doc/coffee-rails-4.2.2/rdoc/fonts/
/usr/share/gems/doc/coffee-script-2.4.1/rdoc/fonts/
/usr/share/gems/doc/coffee-script-source-1.10.0/rdoc/fonts/
/usr/share/gems/doc/erubis-2.7.0/rdoc/fonts/
/usr/share/gems/doc/execjs-2.5.2/rdoc/fonts/
/usr/share/gems/doc/sass-3.5.6/rdoc/fonts/
/usr/share/gems/doc/uglifier-3.1.13/rdoc/fonts/
/usr/share/gems/gems/rdoc-6.7.0/lib/rdoc/generator/template/darkfish/fonts/
/usr/share/octave/8.4.0/fonts/
--
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
# fontconfig handles ttc TrueType collections and otf OpenType fonts and otc
collections
# find Windows non-MS Corp .ttf, all .TTF, .ttc, .otf, and .otc fonts and link
between fonts dirs
# Notes:
# 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;
/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 '*.ot[cf]' -print \) | \
while read f
do
[ -e "$winfontsdir/${f##*/}" ] || /bin/ln -st $winfontsdir/ "$f"
done
/usr/bin/mkfontscale$winfontsdir
/usr/bin/mkfontdir $winfontsdir
for type in opentype truetype
do
texfontsdir=/usr/share/fonts/$type/texmf-dist
/bin/mkdir -p $texfontsdir
# remove any broken links (-L -type l together)
/usr/bin/find -L $texfontsdir -type l -delete
dist=/usr/share/texmf-dist/fonts/$type
#
[ITP] cxref 1.6e+667 - C cross referencing and documenting tool
Cxref produces documentation (in HTML, LaTeX, RTF, or SGML)
including cross-references from C program source code.
Works for ANSI C, including most gcc extensions.
The documentation for the program is produced from comments in the code
that are appropriately formatted.
The cross referencing comes from the code itself and requires no extra work.
The documentation is produced for each of the following:
Files- A comment that applies to the whole file.
Functions- A comment for the function, including a description
of each of the arguments and the return value.
Variables- A comment for each of a group of variables and/or
individual variables.
#include - A comment for each included file.
#define - A comment for each pre-processor symbol definition,
and for macro arguments.
Type definitions - A comment for each defined type and for each element
of a structure or union type.
Any or all of these comments can be present in suitable places in the
source code.
The cross referencing is performed for the following items
Files - The files that the current file is included in (even
when included via other files).
#includes - Files included in the current file.
- Files included by these files etc.
Variables - The location of the definition of external variables.
- The files that have visibility of global variables.
- The files / functions that use the variable.
Functions - The file that the function is prototyped in.
- The functions that the function calls.
- The functions that call the function.
- The files and functions that reference the function.
- The variables that are used in the function.
Each of these items is cross referenced in the output.
Includes extensive README and FAQ with details and examples on how to
use the program.
For more information see the project home page:
http://www.gedanken.org.uk/software/cxref
License:GPL-2.0-only
I would like to provide a Cygwin package for cxref, as I noticed it
is defined in POSIX 2024 but not available under Cygwin.
It is packaged by Debian, OpenSuSE, other minor Linux, Free/NetBSD, and
MacPorts distros:
https://repology.org/project/cxref/versions
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/playground/tree/cxref.cygport?h=playground
package job:
https://cygwin.com/cgi-bin2/jobs.cgi?id=8913&srcpkg=playground&user=Brian+Inglis
log at:
https://github.com/cygwin/scallywag/actions/runs/10909728566/job/30278868009
The package builds and cxrefs itself successfully both locally and under
scallywag GitHub CI.
For changes see below:
2022-04-30
667 Handle "restrict" like other type qualifiers ("const" & "volatile").
2018-08-01
666 Use '-Wall' and '-Wextra' options if the compiler accepts them.
665 Add some more additional extended float types
(including GCC extensions).
664 Add a comment to mark a fall-through in a switch statement.
2017-09-08
663 Add support for extended floating point formats (e.g. _Float128).
2016-03-06
662 Change version number so that it reflects last release plus updates.
2016-02-28
661 Simplify the HTML output.
660 Fix a signed/unsigned comparison found by gcc.
2014-06-05
659 Ignore some new local diff files.
658 Change cexp.c and cexp.y so that the definition of
'struct arglist' matches the one in cccp.c.
657 Add cexp.c to SVN (as it was in the distributed cxref versions).
2014-01-22 1.6e
Bug Fixes
Don't package up unused LSM and ANNOUNCE files.
Pass the CPPFLAGS through to the C compiler
Don't crash on invalid CPP options
Handle the special filename that gcc-4.x uses.
Don't crash on unparseable function declaration
Don't report line number 0 for structures/unions defined within other ones.
Make the HTML 4.01 output use the strict DTD rather than the transitional one.
Handle the gcc _Pragma(...) compiler directives.
Allow gcc 4.8 to be used instead of cxref-cpp (ignore internal #defines).
2011-10-03 1.6d
Bug fixes
Updated for latest version of autoconf.
Allow structure initialisers to have multiple components (e.g. a.b=1).
Remove gcc warning messages.
Change Makefile for better comptibility with FreeBSD.
2010-05-31 1.6c
Bug fixes
Handle the gcc __builtin_offsetof() and offsetof() functions.
Check that the lex/yacc programs actually exist at configure time.
Handle ASM statements with named identifiers in them.
Parsing changes
Removed the char_varying type.
Document changes
Update web page links
2007-02-16 1.6b
Bug fixes
Define a value for PATH_MAX in case one is not already defined.
Fix scope problem with declarations of pointers to functions.
Remove some compilation warnings with gcc 4.
2005-05-01 1.6a
Bug fixes
Adde
[ITP] cflow 1.7 - analyzes C files charting control flow within the program
GNU cflow analyzes a collection of C source files and
prints a graph, charting control flow within the program.
It is able to produce both direct and inverted flowgraphs for C sources.
Optionally a cross-reference listing can be generated.
Two output formats are implemented: POSIX and GNU (extended).
For more information see the project home page:
http://www.gnu.org/software/cflow
License:GPL-2.0-or-later
I would like to provide a Cygwin package for GNU cflow, as I noticed it
is defined in POSIX 2024 but not available under Cygwin.
It is packaged by major Linux and BSD distros:
https://repology.org/project/cflow/versions
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/playground/tree/cflow.cygport?h=playground
package job:
https://cygwin.com/cgi-bin2/jobs.cgi?id=8884&srcpkg=playground&user=Brian+Inglis
log at:
https://github.com/cygwin/scallywag/actions/runs/10758575465/job/29834173442
The package builds and passes all tests successfully both locally and
under scallywag GitHub CI.
For changes see below:
2021-12-30 1.7
- Multiple start functions are allowed
The '--main' option can be given multiple times. A separate graph
will be drawn for each function given as its argument.
- New option --target=FUNCTION
If this option is given, the produced graph will contain only paths
leading from start function (or functions) to the given FUNCTION.
Multiple '--target' options are allowed.
- New output format: dot
The '-f dot' (or '--format=dot') option instructs cflow to output
graph as a description in DOT language, suitable as input to graphviz
programs.
- cflow-mode: new commands for navigating in the graph:
c go to the calling function
n go to the next function at the same nesting level
p go to the previous function at the same nesting level
- Bugfixes:
** CVE-2019-16165
** CVE-2019-16166
** Fix parsing of K&R style function declarations
** Improve parsing of typecasts
** Fix recursive call detection
2019-02-23 1.6
- New option --all (-A)
Produce graphs for all global functions in the program. Use this
option if your program contains functions which are not directly
reachable from main().
The output consist of separate flow graphs for each global function
defined in the program. These graphs will be placed after the graph
for main() (if it exists), and will be ordered lexicographically by
the function name.
- New option --no-main
This option has the same effect as '--all', except that the graph for
main() function (if it exists) is treated same way as all the other
graphs, i.e. it will not be placed at the top of output, but in its
place as per the lexicographic ordering of function names.
2016-05-17 1.5
- Correctly handle functions returning struct/union (fixes bug #31792)
- Gracefully handle invalid inputs (fixes bug #44113)
- Debugging output goes to stderr
- Add a manpage
- Consistent use of exit codes
#|/usr/bin/cygport
# cflow.cygport - cflow Cygwin package build control script definitions
# converted by rpmspec2cygport.sh 1.3 2024-08-15 02:04:42+
NAME=cflow
VERSION=1.7
RELEASE=1
CATEGORY="Devel Text"
SUMMARY="Analyzes C files charting control flow within the program"
DESCRIPTION="GNU cflow analyzes a collection of C source files and
prints a graph, charting control flow within the program.
It is able to produce both direct and inverted flowgraphs for C sources.
Optionally a cross-reference listing can be generated.
Two output formats are implemented: POSIX and GNU (extended)."
HOMEPAGE=http://www.gnu.org/software/$NAME
SRC_URI=mirror://gnu/$NAME/$NAME-$VERSION.tar.xz
SRC_URI+=" $SRC_URI.sig"
DEBIAN=https://sources.debian.org/data/main/${NAME:0:1}/$NAME/$VERSION-$RELEASE/debian/patches
FEDORA=https://src.fedoraproject.org/rpms/$NAME/raw/master/f
OPENSUSE=https://raw.githubusercontent.com/bmwiedemann/openSUSE/master/packages/${NAME:0:1}/$NAME
PATCH_URI=
BUILD_REQUIRES="gettext-devel libiconv-devel libintl-devel
autoconf automake emacs flex gcc-core grep make pkg-config sed"
LICENSE="GPL-2.0-or-later"
# SPDX-License-Identifier: GPL-2.0-or-later
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
LICENSE_URI="COPYING"
DOCS="AUTHORS ChangeLog NEWS README THANKS TODO $LICENCE_URI"
# %make_install
# %find_lang %{name}
# rm -f %{buildroot}/%{_infodir}/dir
# %files -f %{name}.lang
# %{_datadir}/emacs/site-lisp/cflow-mode.el
CYGWIN_MAINTAINER=Brian%20Inglis
CYGWIN_MAINTAINER_EMAIL=brian.ing...@systematicsw.ab.ca
UPSTREAM_MAINTAINER=Upstream%20Maintainer
UPSTREAM_MAINTAINER_EMAIL=upma...@gnu.org
UPSTREAM_EMAIL=$n...@gnu.org
SUBJECT=${OSTYPE^}%20Package%20$NAME%20$VERSION
MAILTO=mailto:$UPSTREAM_MAINTAINER%20%3C$UPSTREAM_MAINTAINER_EMAIL%3E\
,$UPSTREAM_MAINTAINER%20%3C$UPSTREAM_EMAIL%3E\
?from=$CYGWIN_MAINTAINER%20%3C$CYGWIN_MAINTAINER_EMAIL%3E\
\&subject=$SUBJECT\&body=$SUBJECT
Re: cygport bombs any operation when b-r unsatisfied
On 2024-09-15 14:53, Brian Inglis via Cygwin-apps wrote: Hi folks, I would like to check if I have the extensive b-r prereqs to build a package, but cygport immediately bombs out with one missing package at a time! Sorry folks, I was wrong about that! It kind of looks that way when 'inherit ...' is at the top of the cygport. It looks like inherit ... with most cygclasses calls check_prog_req ... for certain required executables, and exits immediately. The bypass to continue is to set or export __cygport_check_prog_req_nonfatal=1! If we do that, then inherit complains but does not exit, and `cygport ... make` lib/check_funcs.cygport: check_depends() checks b-r and warns about all missing b-r packages as desired, which we can then install after killing the build. Could we please make it check all and complain, and maybe just make that a warning, and/or perhaps perform minor operations like *vars* first, or do I have to revert to sourcing and echoing vars, as I did before *vars*? ;^> $ cygport graphviz.cygport vars BUILD_REQUIRES /usr/share/cygport/cygclass/php.cygclass: line 142: /usr/bin/pear: No such file or directory /usr/share/cygport/cygclass/php.cygclass: line 150: /usr/bin/pear: No such file or directory *** ERROR: ocaml is required to build this package -- 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
cygport bombs any operation when b-r unsatisfied
Hi folks, I would like to check if I have the extensive b-r prereqs to build a package, but cygport immediately bombs out with one missing package at a time! Could we please make it check all and complain, and maybe just make that a warning, and/or perhaps perform minor operations like *vars* first, or do I have to revert to sourcing and echoing vars, as I did before *vars*? ;^> $ cygport graphviz.cygport vars BUILD_REQUIRES /usr/share/cygport/cygclass/php.cygclass: line 142: /usr/bin/pear: No such file or directory /usr/share/cygport/cygclass/php.cygclass: line 150: /usr/bin/pear: No such file or directory *** ERROR: ocaml is required to build this package -- 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] desktop-file-utils 0.27 - utilities for manipulating desktop files
On 2024-09-15 09:11, Jon Turney wrote:
On 14/09/2024 01:30, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and update desktop-file-utils as it validates
former mime-types now media-types, and does not even support fonts,
issuing errors during setup:
Thanks!
I added this to your packages.
[...]
Build has been changed from autotools (no longer supported) to meson.
I would like advice on how to name and where to install the emacs files,
as the Fedora spec (in Cygport comments) desktop-file-utils differs from
our previous name desktop-entry-mode.
I'm not sure what the precise difficulty with emacs is here.
No difficulty: Cygwin puts the Emacs script under site-lisp, and Fedora puts it
into a site-lisp subdirectory desktop-file-utils, and provides a startup script
desktop-entry-mode-init.el under site-startdir which emacs.cygclass does not
define, nor Cygwin create - seems overkill for a script?
The emacs cygclass [1] provides some help with this, if the meson build doesn't
install things into the right place anyhow.
It does DTRT.
[1] https://cygwin.github.io/cygport/emacs_cygclass.html#emacs.cygclass
Should have been using that, so I'll do so in cygport.
Cygwin does straight ...CONTENTS:
usr/share/emacs/site-lisp/desktop-entry-mode.*
so if I inherit emacs and use $EMACS_SITE do I need ${EMACS_SITE#/}?
Maybe I can and should get rid of ...CONTENTS, as the original maintainer may
have been considering a separate subpackage for the Emacs script.
Fedora does:
# %{_emacs_sitelispdir}/desktop-file-utils/
# mkdir -p $RPM_BUILD_ROOT%{_emacs_sitelispdir}/desktop-file-utils
# mv $RPM_BUILD_ROOT%{_emacs_sitelispdir}/*.el*
$RPM_BUILD_ROOT%{_emacs_sitelispdir}/desktop-file-utils
# install -Dpm 644 %{SOURCE1}
$RPM_BUILD_ROOT%{_emacs_sitestartdir}/desktop-entry-mode-init.el
# touch $RPM_BUILD_ROOT%{_emacs_sitestartdir}/desktop-entry-mode-init.elc
--
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] Perl 5.40 Rebuilds Needed
On 2024-08-25 13:42, Brian Inglis via Cygwin-apps wrote: On 2024-08-25 07:25, Jon Turney via Cygwin-apps wrote: On 18/08/2024 18:56, ASSI via Cygwin-apps wrote: I'm going to release Perl 5.40.0 to Cygwin in a few days. I've skipped 5.38 in order to update only every second year (which I've done since the 5.22 release). I haven't seen any trouble in my own Perl distribution packages from the update even though there are lots of them that haven't been updated since at least 5.22. So I hope it will be smooth sailing for anything else depending on Perl also. Any maintainer having packages that depend on perl5_036 or below should re-release or upgrade these soon-ish after the Perl update is available, as otherwise users are either blocked from upgrading Perl or will have to uninstall the affected packages. The rebuilt packages need to have a dependency on perl5_040, which cygport provides automatically when building with the new Perl. Packages that need an update from perl5_036 are: [...] The current list of things still needing rebuilds can be found at: https://cygwin.com/packages/reports/perl_rebuilds.html Just to reassure maintainers and encourage adopters: graphviz ORPHANED libproxy ORPHANED link-grammar ORPHANED net-snmp ORPHANED openwsman ORPHANED marisa ORPHANED ming ORPHANED DONE nginx ORPHANED xfconf ORPHANED zbar ORPHANED DONEMaintained zinnia ORPHANED I would think graphviz and nginx might have lots of users? Any ideas what others may have significant dependencies or users? Jon did NMUs on these last year, so they should be in decent shape for adopters - any maintainers who are users and would be interested takers? GraphicsMagick Marco Atzeri ImageMagick Marco Atzeri postgresql Marco Atzeri subversion Marco Atzeri hexchat Marco Atzeri irssi Marco Atzeri weechat Sebastien Helleu DONE openbabel Lemures Lemniscati DONE stow Andrew Schulman znc Alexey Sokolov libsolv Jon Turney DONE po4a Erwin WaterlanderDONE The remaining packages needing rebuilt with perl 5.40 are: $ lynx -dump -nolist https://cygwin.com/packages/reports/perl_rebuilds.html Packages needing rebuilds for latest perl_base Packages whose latest version depends on a version provides: other than perl5_040. package srcpackage version depends hexchat-perl hexchat2.16.1-1 perl5_036 irssiirssi 1.4.5-1 perl5_036 net-snmp-agent-libs net-snmp 5.9.3-2 perl5_036 nginx-mod_http_perl nginx 1.24.0-1 perl5_036 perl-Graphics-Magick GraphicsMagick 1.3.40-2 perl5_036 perl-Image-MagickImageMagick7.0.10.61-1 perl5_036 perl-Net-Libproxylibproxy 0.4.18-1 perl5_036 perl-Stowstow 2.4.0+5.36-1 perl5_036 perl-Xfce4-Xfconfxfconf 4.12.0-3 perl5_036 perl-clinkgrammarlink-grammar 5.12.3-1 perl5_036 perl-gv graphviz 8.0.5-1 perl5_036 perl-marisa marisa 0.2.4-5 perl5_036 perl-net-snmpnet-snmp 5.9.3-2 perl5_036 perl-openwsman openwsman 2.7.2-1 perl5_036 perl-zinnia zinnia 0.07-1 perl5_036 postgresql-contrib postgresql 16.2-1 perl5_036 postgresql-plperlpostgresql 16.2-1 perl5_036 subversion-perl subversion 1.14.2-1 perl5_036 znc-perl znc1.9.1-1 perl5_036 Maintained: $ cygcheck-dep -cqSr irssi perl-Graphics-Magick perl-Image-Magick postgresql-contrib postgresql-plperl subversion-perl hexchat-perl perl-Stow znc-perl irssi: requires ( cygwin libglib2.0-devel libglib2.0_0 libncursesw10 libssl3 perl-libwww-perl perl_base pkg-config perl5_036 ) perl-Graphics-Magick: requires ( cygwin libgcc1 libGraphicsMagick3 perl_base perl5_036 ) perl-Image-Magick: requires ( cygwin libMagickCore7_9 perl_base perl5_036 ) postgresql-contrib: requires ( cygwin libgcc1 libintl8 libpq5 libssl3 perl_base postgresql python39 zlib0 perl5_036 ) postgresql-plperl: requires ( cygwin libgcc1 perl perl_base postgresql perl5_036 ) subversion-perl: requires ( cygwin libapr1 libgcc1 perl_base subversion perl5_036 ) hexchat-perl: requires ( cygwin hexchat libgcc1 libglib2.0_0 perl_base perl5_036 ) perl-Stow: requires ( perl_base perl5_036 ) znc-perl: requires ( cygwin libgcc1 libstdc++6 perl_base znc perl5_036 ) Orphaned/Unmaintained: $ cygcheck-dep -cqSr net-snmp-agent-libs nginx-mod_http_perl perl-gv perl-Net-Libproxy perl-clinkgrammar perl-net-snmp perl-openwsman perl-marisa perl-Xfce4-Xfconf perl-zinnia net-snmp-agent-libs: requires ( cygwin libpcre
[ITA] desktop-file-utils 0.27 - utilities for manipulating desktop files
I would like to adopt and update desktop-file-utils as it validates
former mime-types now media-types, and does not even support fonts,
issuing errors during setup:
Error in file "/usr/share/applications/org.fontforge.FontForge.desktop":
"font/otf" is an invalid MIME type ("font" is an unregistered media type)
Error in file "/usr/share/applications/org.fontforge.FontForge.desktop":
"font/ttf" is an invalid MIME type ("font" is an unregistered media type)
Error in file "/usr/share/applications/org.fontforge.FontForge.desktop":
"font/woff" is an invalid MIME type ("font" is an unregistered media type)
Error in file "/usr/share/applications/org.fontforge.FontForge.desktop":
"font/woff2" is an invalid MIME type ("font" is an unregistered media type)
Build has been changed from autotools (no longer supported) to meson.
I would like advice on how to name and where to install the emacs files,
as the Fedora spec (in Cygport comments) desktop-file-utils differs from
our previous name desktop-entry-mode.
Description:
Desktop files describe applications to show in GNOME or KDE menus:
desktop-file-validate checks whether a .desktop file complies with the
specification at http://www.freedesktop.org/standards/;
desktop-file-install installs a .desktop file to the standard directory,
optionally fixing it up in the process.
License:GPL-2.0-or-later
For more info see the project home page:
https://freedesktop.org/wiki/Software/desktop-file-utils
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/desktop-file-utils/tree/desktop-file-utils.cygport?h=playground
package build:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=desktop-file-utils
log at:
https://github.com/cygwin/scallywag/actions/runs/10857533685/job/30134155527
For changes since the previous Cygwin release see below:
2023-10-05 0.27
common
- Remove Autotools support.
- Minor updates to project documentation.
- Add pledge(2) support to remaining utilities
- Add --version support to utilities
desktop-file-validate
- Support desktop spec version 1.5
- Add LXQt to categories
- Use DDE category for Deepin desktop
- Add Endless to list of desktop IDs
- Fix field code escaping in messages
desktop-entry-mode.el
- Highlight action groups when ID includes hyphens
2020-06-19 0.26
This version fixes an error that snuck into the Meson build files in
version 0.25. The Autotools build is unaffected. Since the previous
release has only been out for a day, Autotools support is maintained in
this release.
update-desktop-database
- Fix erroneous installation as "desktop-file-update" when using the
Meson build system
2020-06-18 0.25
This version adds support for the Meson build system and deprecates
Autotools. Support for the latter will be removed in the next release.
common
- Add Meson build system
desktop-file-validate
- Allow desktop file spec version 1.4.
- Make it possible to deprecate keys starting with "X-"
- Add the "Implements" field from spec version 1.2
- Add the "PrefersNonDefaultGPU" key and deprecate "X-KDE-RunOnDiscreteGpu"
- Set locale for correct output message encoding
- Add coloured output support
- Fix parsing of escaped double quote in quoted strings
- Add GNOME Flashback, GNOME Classic desktops
2019-07-25 0.24
desktop-file-validate
- Allow desktop file spec version 1.2
- Add Budgie, Deepin, Enlightenment and Pantheon to list of
registered desktop environments
update-desktop-database
- Sort output lines internally to conserve reproduceability
- Use pledge(2) on OpenBSD to limit capabilities
common
- Fix missing ; when appending to a list not ending with one
- Add font as valid media type
- Fix broken emacs blocking compile
#|/usr/bin/cygport
# desktop-file-utils.cygport - desktop-file-utils Cygwin package build control
script definitions
NAME=desktop-file-utils
VERSION=0.27
RELEASE=1
CATEGORY="X11 Utils"
SUMMARY="utilities for manipulating desktop files"
DESCRIPTION="Desktop files describe applications to show in GNOME or KDE menus:
desktop-file-validate checks whether a .desktop file complies with the
specification at http://www.freedesktop.org/standards/;
desktop-file-install installs a desktop file to the standard directory,
optionally fixing it up in the process."
HOMEPAGE=https://freedesktop.org/wiki/Software/desktop-file-utils
SRC_URI=https://freedesktop.org/software/$NAME/releases/$NAME-$VERSION.tar.xz
SRC_URI+=" $SRC_URI.asc"# $SRC_URI.sha256sum
LICENSE=GPL-2.0-or-later
LICENSE_URI=COPYING
DOCS="AUTHORS README NEWS $LICENSE_URI"
BUILD_REQUIRES="libglib2.0-devel libintl-devel emacs meson ninja pkg-config"
desktop_file_utils_CONTENTS="
etc/postinstall/zp_$NAME.sh
etc/preremove/$NAME.sh
usr/bin/
usr/share/doc/$NAME/
usr/share/emacs/site-lisp/desktop-entry-mode.*
usr/share/man/man1/desktop-file-*.1*
usr/share/man/man1/update-desktop-database.1*
"
# %{_emacs_sitelispdir}/desktop-file-uti
Scallywag builds no longer showing build status - stuck showing 'fetching metadata'
Hi folks, Scallywag builds are no longer showing the build or deploy status on the jobs web page since the access issue yesterday, but all seem to be stuck showing "fetching metadata" although each process has succeeded, as confirmed in the logs. Manual upload calm processing is working normally, and setup.ini is updated properly. -- 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] zint 2.13.0 - multi-format barcode encoder
On 2024-08-31 23:51, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: most other test issues appear to be what they interpret as file access writing to a file they make readonly, but looks like errno 10 - ECHILD 10 No child processes? That sort of test usually fails when run with a user token that has backup/restore privileges, which you can get rid of via cygdrop (this sometimes trigger different fails with other tests). If you are using DLL from build directories you might also run into fork errors, so an ephemeral rebase could help. Thanks Achim, Awesome inspiration! Whether from rebasing, and/or dropping privileges, and/or both, no change in local tests all passing, but now scallywag tests are also all passing. Soo-wee! Woo-hoo! Yee-haa! Do you have any links or refs to why those privs cause failures? I found one article that implies that with those privs, CreateFile() needs flag FILE_FLAG_BACKUP_SEMANTICS or access fails! Does that sound about right? -- 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 package builds all failing - GitHub CI can not clone Cygwin package repos
Last few Scallywag GitHub CI jobs today from Takashi and myself after 10:00Z
GMT have failed accessing package repos for cygwin and zint in source/build
step 6 Build packages:
There was a DoS, now corrected.
- FChE
Thanks Frank,
For your very quick response.
Confirmed - git clone git:// working:
Run export PATH=/usr/bin:/usr/local/bin:$(cygpath ${SYSTEMROOT})/system32
scallywag: input args are {'BUILDNUMBER': 8874, 'COMMIT':
'3719953ff639c9f3136d6102a8b94cc2c786e163', 'DEFAULT_TOKENS': '', 'MAINTAINER':
'Brian Inglis', 'PACKAGE': 'zint', 'REFERENCE': 'refs/heads/playground'}
scallywag: package is zint
Initialized empty Git repository in /cygdrive/d/a/scallywag/zint/.git/
From git://cygwin.com/git/cygwin-packages/zint
* branch3719953ff639c9f3136d6102a8b94cc2c786e163 -> FETCH_HEAD
Reset branch 'master'
scallywag: repository contains cygport zint.cygport
Jobs rerunning!
--
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 package builds all failing - GitHub CI can not clone Cygwin package repos
Hi folks,
Last few Scallywag GitHub CI jobs today from Takashi and myself after 10:00Z GMT
have failed accessing package repos for cygwin and zint in source/build step 6
Build packages:
Run export PATH=/usr/bin:/usr/local/bin:$(cygpath ${SYSTEMROOT})/system32
scallywag: input args are {'BUILDNUMBER': 8869, 'COMMIT':
'a97863b93c7403ca8a306a63f33fcd6223b1d056', 'DEFAULT_TOKENS': ' deploy label',
'MAINTAINER': 'Takashi Yano', 'PACKAGE': 'cygwin', 'REFERENCE': 'refs/heads/master'}
scallywag: package is cygwin
Initialized empty Git repository in /cygdrive/d/a/scallywag/cygwin/.git/
fatal: unable to connect to cygwin.com:
cygwin.com[0: 8.43.85.97]: errno=Connection refused
cygwin.com[1: 2620:52:3:1:0:246e:9693:128c]: errno=Network is unreachable
scallywag: something went wrong cloning the package repo
Error: Process completed with exit code 1.
Clicking on the jobs page commit links show me the package repo commits.
Local https:// and ssh:// clones work okay, but git:// fails as above:
$ git clone git://cygwin.com/git/cygwin-packages/zint
Cloning into 'zint'...
fatal: unable to connect to cygwin.com:
cygwin.com[0: 2620:52:3:1:0:246e:9693:128c]: errno=Connection refused
cygwin.com[1: 8.43.85.97]: errno=Connection refused
$ getent services git
git 9418/tcp
Possibly a block or no allow on git port 9418 for virtual host Cygwin.com or
from GitHub.com?
--
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
--
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 package builds all failing - GitHub CI can not clone Cygwin package repos
Hi folks,
Last few Scallywag GitHub CI jobs today from Takashi and myself after 10:00Z GMT
have failed accessing package repos for cygwin and zint in source/build step 6
Build packages:
Run export PATH=/usr/bin:/usr/local/bin:$(cygpath ${SYSTEMROOT})/system32
scallywag: input args are {'BUILDNUMBER': 8869, 'COMMIT':
'a97863b93c7403ca8a306a63f33fcd6223b1d056', 'DEFAULT_TOKENS': ' deploy label',
'MAINTAINER': 'Takashi Yano', 'PACKAGE': 'cygwin', 'REFERENCE': 'refs/heads/master'}
scallywag: package is cygwin
Initialized empty Git repository in /cygdrive/d/a/scallywag/cygwin/.git/
fatal: unable to connect to cygwin.com:
cygwin.com[0: 8.43.85.97]: errno=Connection refused
cygwin.com[1: 2620:52:3:1:0:246e:9693:128c]: errno=Network is unreachable
scallywag: something went wrong cloning the package repo
Error: Process completed with exit code 1.
Clicking on the jobs page commit links show me the package repo commits.
Local https:// and ssh:// clones work okay, but git:// fails as above:
$ git clone git://cygwin.com/git/cygwin-packages/zint
Cloning into 'zint'...
fatal: unable to connect to cygwin.com:
cygwin.com[0: 2620:52:3:1:0:246e:9693:128c]: errno=Connection refused
cygwin.com[1: 8.43.85.97]: errno=Connection refused
$ getent services git
git 9418/tcp
Possibly a block or no allow on git port 9418 for virtual host Cygwin.com?
--
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] zint 2.13.0 - multi-format barcode encoder
On 2024-08-31 09:22, Jon Turney wrote: On 27/08/2024 20:54, Brian Inglis via Cygwin-apps wrote: Zint does easy barcode data encoding in a wide range of standard formats and supports integration into programs. License: GPL-3.0-or-later AND BSD-3-Clause For more information see the project home page: http://zint.org.uk I have successfully rebuilt the package locally with a patch for not quite new enough Qt, added licence, b-r packages, and installed docs, and cmake scripts and pushed to playground: https://cygwin.com/git/?p=git/cygwin-packages/zint.git built under scallywag GH CI: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=zint log at: https://github.com/cygwin/scallywag/actions/runs/10584126970/job/29327864619 There are issues with not building a Qt GUI backend dll, nor tcl support, and tests not running due to startup failures. The last failure looks like you need to be running the tests with xvfb_run [1]. I didn't examine the others. I don't really get a sense of what you think should be done about these issues. [1] https://cygwin.github.io/cygport/xvfb_cygclass.html#xvfb_run Thanks Jon, Greatly appreciate the tip about xvfb_run etc. As for the package issues, it looks like they decided a GUI .so was no longer required, so will not do a dynamic build as distributed; their mention of tcl does not appear to be reflected in the cmake files as far as I can see; some test issues were resolved by exporting PATH containing all of the build directories; most other test issues appear to be what they interpret as file access writing to a file they make readonly, but looks like errno 10 - ECHILD 10 No child processes? The next Scallywag run should hopefully provide some more 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] zbar 0.23.93 - barcode image decoder
On 2024-08-29 15:09, Jon Turney via Cygwin-apps wrote: On 26/08/2024 23:36, Brian Inglis via Cygwin-apps wrote: ZBar reads bar codes from sources such as video streams, image files, and raw intensity sensors. It supports many popular types of bar code symbologies including EAN-8, EAN-13, UPC-A, UPC-E, Code 39, Code 93, Code 128, Interleaved 2 of 5, GS1 DataBar (RSS-14), QR Code, and SQ Code. License: LGPL-2.1-or-later For more information see the project home page: https://github.com/mchehab/zbar I have successfully rebuilt the package locally with some patch adjustments for changes incorporated and new patches for config changes, some new and changed b-r packages, and pushed to playground: Thanks very much for looking at this! You have NMU privileges, so you don't need to adopt this if you're just doing a "drive-by update". I want to adopt as I use zbar and zint when decoding and encoding bar codes for my own interest, as when we all had to carry and show QR-encoded vaccination "passports" for scanning to get access to some "public" spaces and events. [Despite this I had been blocked from entering a restaurant where I was to meet friends for a meal, because I only had my *legal* "temporary" driver's licence, while waiting to receive its scheduled replacement, and multiple other legal forms of id, so was interested to ensure that would never recur! We all left for somewhere better, and the place eventually went bust! ;^>] If you're touching this, can you also do what I should have done and make a versioned python package e.g. python39-zbar, which is required by a virtual python-zbar package (as per the example in https://cygwin.com/packaging/cygport_tips.html). Thanks for pointing out that tip and the example to follow - I will do that here, and also elsewhere when python bits are involved. I was more focussed on getting this done for the perl update! Changes tested successfully locally and pushed: https://cygwin.com/cgit/cygwin-packages/zbar/commit/?h=playground run in scallywag: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=zbar&id=8865&user=Brian+Inglis with same results as locally: https://github.com/cygwin/scallywag/actions/runs/10629920088/job/29468282882 https://cygwin.com/git/?p=git/cygwin-packages/zbar.git built under scallywag GH CI: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=zbar log at: https://github.com/cygwin/scallywag/actions/runs/10566715776/job/29274446760 There are the same 3 missing and 3 spurious code matches out of 100,000 tests locally and under scallywag. Previous version also has: [28417] SEED=-1466011001: warning: expecting DataBar, got spurious EAN-2 [35442] SEED=-591992353: missing decode: CODE-39 (YP%CC-.) [64558] SEED=1906143625: missing decode: CODE-128 (41714534408557) [79042] SEED=-1776449378: missing decode: CODE-39 (Z5EKHI5I6) [84522] SEED=-966054662: warning: expecting DataBar, got spurious EAN-2 [98350] SEED=1992973531: warning: expecting DataBar, got spurious EAN-2 decoder PASSED with 3 spurious (0.0030%) and 3 missing(0.0030%). So I think this is the expected result? Nice that there are undocumented possible XFAILs, unless this is some Cygwin glitch, but unlikely with the other ~100k tests succeeding? -- 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
[ITP?] wcurl - simple download wrapper
Hi folks, The curl project has adopted wcurl - a simple download wrapper shell script that makes it easy to do what wget2 does using curl, setting output defaults, names, timestamps, downloading in parallel, etc. https://github.com/curl/wcurl It is available under Alpine, Arch, Homebrew, Mac, Msys2, NetBSD, and a couple of others so far: https://repology.org/project/wcurl/versions It consists of a shell script wcurl, man page wcurl.1, README.md, LICENSE, LICENSES/curl.txt, and tests/test.sh. As curl maintainer, I question whether this should be packaged separately, or just included in the curl package, with the sources downloaded into a subdirectory from git with a download hook, and installed from there? The latter is done in playground: https://cygwin.com/git/?p=git/cygwin-packages/curl.git;a=commitdiff;h=playground build: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=curl&id=8864 log: https://github.com/cygwin/scallywag/actions/runs/10609422666/job/29405185296 The local build is on make check, and scallywag is still building the package. Any advice and comments on best approaches to this would be appreciated. -- 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] zint 2.13.0 - multi-format barcode encoder
Zint does easy barcode data encoding in a wide range of standard formats and supports integration into programs. License:GPL-3.0-or-later AND BSD-3-Clause For more information see the project home page: http://zint.org.uk I have successfully rebuilt the package locally with a patch for not quite new enough Qt, added licence, b-r packages, and installed docs, and cmake scripts and pushed to playground: https://cygwin.com/git/?p=git/cygwin-packages/zint.git built under scallywag GH CI: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=zint log at: https://github.com/cygwin/scallywag/actions/runs/10584126970/job/29327864619 There are issues with not building a Qt GUI backend dll, nor tcl support, and tests not running due to startup failures. For changes since the previous Cygwin release see below: 2023-12-18 2.13.0 *Incompatible changes* - Buffer lengths of members `fgcolour` and `bgcolour` in `zint_symbol` extended 10 -> 16 to allow for "C,M,Y,K" comma-separated decimal percentage strings - CMYK values for EPS (slightly) and TIF (significantly) have changed - now use the same RGB -> CMYK formula - Text (HRT) placement for vector (EMF/EPS/SVG) output changed - for EAN/UPC slightly further away from barcode, for all others slightly nearer. Some horizontal alignments of EAN/UPC vector text also tweaked - Text (HRT) for standalone EAN-2 and EAN-5 now at top of symbol (was at bottom) - Text height (font size) for SMALL_TEXT vector output reduced - For Windows, filenames are now assumed to be UTF-8 encoded. Affects `outfile` in `zint_symbol` and all API filename arguments - Never-used `fontsize` member removed from `zint_symbol` - Buffer length of member `text` (HRT) in `zint_symbol` extended 128 -> 200 (client buffers may need checking/extending) - Font of text of SVG vector output now "OCRB, monospace" (EAN/UPC) or "Arimo, Arial, sans-serif" (all others) (was "Helvetica, sans-serif" for both) - Unintended excess horizontal whitespace of Composite symbols removed, and quiet zone settings respected exactly, and centring of HRT (if any) now relative to linear part of symbol only rather than whole symbol - Unlikely-to-be-used `bitmap_byte_length` member removed from `zint_symbol` (was only set on BMP output to length of BMP pixel array) - EXCODE39 now defaults to displaying check digit in Human Readable Text (HRT) - GS1_128 now warns if data > 48 (GS1 General Specifications max) Changes - BMP/EMF/EPS/GIF/PCX/PNG/SVG/TIF/TXT: check for errors on writing to output file (ticket #275) - manual/man page: document octal escape; Code 128 subset/mode -> Code Set - Add special symbology-specific escape sequences (Code 128 only) for manual Code Set switching via `input_mode` flag `EXTRA_ESCAPE_MODE` (CLI --extraesc) (ticket #204) - GUI: disable "Reset" colour if default; add "Unset" to Printing Scale dialog (allows unsetting of X-dim/resolution settings without having to zap) - API/CLI/GUI: allow foreground/background colours to be specified as comma-separated decimal percentage strings "C,M,Y,K" where "C", "M" etc. are 0-100 (ticket #281, 3rd point) - PCX: add alpha support - GUI: rearrange some Appearance tab inputs (Border Type <-> Width, Show Text <-> Font, Text/Font <-> Printing Scale/Size) to flow more naturally; save button "Save As..." -> "Save..." and add icon - Add `text_gap` option to allow adjustment of vertical gap between barcode and text (HRT) - DAFT: up max to 250 chars - CLI: use own (Wine) version of `CommandLineToArgvW()` to avoid loading "shell32.dll" - EAN/UPC: add quiet zone indicators option (API `output_options` `EANUPC_GUARD_WHITESPACE`, CLI `--guardwhitespace`) (ticket #287) - EAN-2/EAN-5: HRT now at top instead of at bottom for standalones, following BWIPP - EPS/SVG: use new `out_putsf()` func to output floats, avoiding trailing zeroes & locale dependency - EPS: simplify "TR" formula - SVG: change font from "Helvetica, sans-serif" to "OCRB, monospace" for EAN/UPC and "Arimo, Arial, sans-serif" for all others; use single "" instead of multiple ""s to draw boxes (reduces file size) - Add `EMBED_VECTOR_FONT` to `output_options` (CLI `--embedfont`) to enable embedding of font in vector output - currently only for SVG output - GUI: use "OCRB" font for EAN/UPC and "Arimo" for all others (was "Helvetica" for both); add preview background colour option (default light grey) so as whitespace will show up in contrast (access via preview context menu) - CODE128/common: add `ZINT_WARN_HRT_TRUNCATED` warning - QRCODE: better assert(), removing a NOLINT (2 left) - CLI: add some more barcode synonyms for DBAR - CMake: don't include png.c unless ZINT_USE_PNG (avoids clang warning) - vector: reduce SMALL_TEXT font height 6 -> 5 to be more like raster; reduce antialiasing allowance for `textoffset`; adjust text to baseline using values for Arimo rather than percentage - manual: expand size/alpha details i
[ITA] zbar 0.23.93 - barcode image decoder
ZBar reads bar codes from sources such as video streams, image files, and raw intensity sensors. It supports many popular types of bar code symbologies including EAN-8, EAN-13, UPC-A, UPC-E, Code 39, Code 93, Code 128, Interleaved 2 of 5, GS1 DataBar (RSS-14), QR Code, and SQ Code. License:LGPL-2.1-or-later For more information see the project home page: https://github.com/mchehab/zbar I have successfully rebuilt the package locally with some patch adjustments for changes incorporated and new patches for config changes, some new and changed b-r packages, and pushed to playground: https://cygwin.com/git/?p=git/cygwin-packages/zbar.git built under scallywag GH CI: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=zbar log at: https://github.com/cygwin/scallywag/actions/runs/10566715776/job/29274446760 There are the same 3 missing and 3 spurious code matches out of 100,000 tests locally and under scallywag. For changes since the previous Cygwin release see below: 2024-01-09 0.23.93 - Set a better dpi resolution when parsing PDF files - Fix memory recycle bug of empty symbols - Fix compilation with python 3.11 and 3.12 - CVE-2023-40889: Fix array out-of-bounds access - Stop ignoring non-binary entries that follow binary ones - Increase allocated buffer memory for symbols - barcodetest.py: fix error code print logic - convert: Crash fixing while using camera - Add some pod information for additional functions - perl skip more tests if DISPLAY not set and set prereqs in Makefile.PL - Fixes rt.cpan.org 122061 - test fails when DISPLAY not set - Update Barcode::ZBar - isaac: ensure proper order of parsing expression - Enforce x11 backend even on wayland - zbarimg: add the --polygon option - xml output: Add polygon containing code bar. - configure.ac: drop support for Qt4 and prepare for Qt6 support - win: fix compiling error in Visual studio - Enforce a coding style - configure.ac: fix some issues with gtk parameter - zbargtk: fix version check macros - zbar: Address some header issues - zbar, test: fix compilation issues with FreeBSD - zbar: Function stdcall declaration issue. - symbol: make it compatible with MSC - zbar: change the code to make it c90 standard compatible - test: fix decode test 2021-02-21 0.23.92 - Added --enable-static to make easier to distribute Windows binaries 2021-02-14 0.23.91 - No functional changes. Just Gitlab workflow changes to release binaries. 2021-02-14 0.23.90 - Started using github actions for CI and binary releases - Fixed several issues with configure.ac, making it auto-detect most things, when possible - README.md now shows the absolute minimum requirement for building ZBar on Ubuntu - Fixed some build issues - Make it compatible with Python 3.9 - Fixed some Python 3.9 and Qt5 warnings - Typo fixes - Several fixes at zbarcam - zbarimg: fix stderr output when symbols are found
Re: [Attn. MAINTAINERS] Heads up: Perl 5.40.0 is imminent
On 2024-08-25 07:25, Jon Turney via Cygwin-apps wrote: On 18/08/2024 18:56, ASSI via Cygwin-apps wrote: I'm going to release Perl 5.40.0 to Cygwin in a few days. I've skipped 5.38 in order to update only every second year (which I've done since the 5.22 release). I haven't seen any trouble in my own Perl distribution packages from the update even though there are lots of them that haven't been updated since at least 5.22. So I hope it will be smooth sailing for anything else depending on Perl also. Any maintainer having packages that depend on perl5_036 or below should re-release or upgrade these soon-ish after the Perl update is available, as otherwise users are either blocked from upgrading Perl or will have to uninstall the affected packages. The rebuilt packages need to have a dependency on perl5_040, which cygport provides automatically when building with the new Perl. Packages that need an update from perl5_036 are: [...] The current list of things still needing rebuilds can be found at: https://cygwin.com/packages/reports/perl_rebuilds.html Just to reassure maintainers and encourage adopters: graphviz ORPHANED libproxy ORPHANED link-grammar ORPHANED net-snmp ORPHANED openwsman ORPHANED marisa ORPHANED ming ORPHANED nginx ORPHANED xfconf ORPHANED zbar ORPHANED zinnia ORPHANED I would think graphviz and nginx might have lots of users? Any ideas what others may have significant dependencies or users? Jon did NMUs on these last year, so they should be in decent shape for adopters - any maintainers who are users and would be interested takers? GraphicsMagick Marco Atzeri ImageMagickMarco Atzeri postgresql Marco Atzeri subversion Marco Atzeri hexchatMarco Atzeri irssi Marco Atzeri weechatSebastien Helleu openbabel Lemures Lemniscati stow Andrew Schulman zncAlexey Sokolov libsolvJon Turney po4a Erwin Waterlander -- 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 cygclass/python.org.cygclass pythonhosted archives may require underscores not dashes
new source packages on pythonhosted appear to change dashes in package
names to underscores in archive names and directories, for example:
python-license-expression ->
license-expression ->
https://files.pythonhosted.org/packages/source/l/license_expression/license_expression-30.3.1.tar.gz
-> license_expression-30.3.1/
although dashes in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license_expression-30.3.1.tar.gz
but dashes work and underscores do not in older package version
archives, although underscores in pythonhosted package directory names
still seem to work as an alternative:
https://files.pythonhosted.org/packages/source/l/license{-,_}expression/license-expression-30.3.0.tar.gz
so keep pythonhosted package directory names verbatim and iterate setting
SRC_DIR to package name verbatim or underscored and test availability with:
wget -q --spider ...
or
curl --silent --fail -o /dev/null 2> /dev/null ...
Signed-off-by: Brian Inglis
---
cygclass/python.org.cygclass | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cygclass/python.org.cygclass b/cygclass/python.org.cygclass
index 51434ba6c08f..a1b8fb89ec73 100644
--- a/cygclass/python.org.cygclass
+++ b/cygclass/python.org.cygclass
@@ -50,4 +50,8 @@ HOMEPAGE="https://pypi.org/project/${PYTHON_ORG_NAME}";
# DESCRIPTION
# Download location of the Python module on the Python Package Index.
#
-SRC_URI="https://files.pythonhosted.org/packages/source/${PYTHON_ORG_NAME:0:1}/${PYTHON_ORG_NAME}/${PYTHON_ORG_NAME}-${PV}.tar.gz";
+for SRC_DIR in ${PYTHON_ORG_NAME}-${PV} ${PYTHON_ORG_NAME//-/_}-${PV}
+do
+
SRC_URI=https://files.pythonhosted.org/packages/source/${PYTHON_ORG_NAME:0:1}/${PYTHON_ORG_NAME}/${SRC_DIR}.tar.gz
+wget --quiet --spider $SRC_URI && break
+done
--
2.45.1
Re: less on /proc files
On 2024-08-05 16:20, Corinna Vinschen via Cygwin-apps wrote:
Hi Marco,
Achim made me aware yesterday, that less(1) shows nothing at all when
called on files under /proc.
Turns out, this only works on Linux, because there's a Linux-specific
kludge in less, checking if a file of size 0 is on the /proc filesystem
and if so, handles it accordingly.
Unfortunately the Linux kludge won't work for Cygwin without adding new
stuff to Cygwin:
- A file, which sounds a bit weird, and
- adding real f_type info to statfs().
This would make less on /proc files only work starting with Cygwin 3.6,
but there's another, simpler solution working with all recent Cygwin
versions. I created a small patch to less, doing a simple path check
and then handling /proc files just as in the Linux-specific code:
--- origsrc/less-643/ch.c 2023-07-21 00:43:12.0 +0200
+++ src/less-643/ch.c 2024-08-05 22:37:03.10500 +0200
@@ -719,6 +719,20 @@ public void ch_flush(void)
}
}
}
+#elif defined (__CYGWIN__)
+ if (ch_fsize == 0)
+ {
+ char proclink[PATH_MAX];
+ char filename[PATH_MAX];
+ snprintf(proclink, sizeof proclink, "/proc/%u/fd/%d",
+getpid(), ch_file);
+ if (readlink(proclink, filename, sizeof filename) > 6 &&
+ strncmp (filename, "/proc/", 6) == 0)
+ {
+ ch_fsize = NULL_POSITION;
+ ch_flags &= ~CH_CANSEEK;
+ }
+ }
#endif
if (lseek(ch_file, (off_t)0, SEEK_SET) == BAD_LSEEK)
Would it be ok for you to push out a new less release with this or a
similar patch?
Current less 661 now handles that unconditionally in cl_flush() from ch_init():
https://github.com/gwsw/less/blob/master/ch.c#L860
I got rid of my ~/.lessfilter to feed 'more /proc/...' to less!
--
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 not processing since yesterday
Hi folks, Uploaded new curl version and no sign of being picked up by calm after nearly 2 hours. No sign setup has been updated in the last day. Uploaded new !ready files to see if anything will change. -- 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 not updating master x86_64/sha512.sum after setup updates
Hi folks, After uploading packages, calm does not appear to be updating sha512.sum after updating setup.ini: $ date -ud@`stat -c%Y ~/mirror/x86_64/sha512.sum` 2024 Jul 24 Wed 15:14:03 This is showing up in a script I run a minute or few later to check git/cygwin-packages/repo status, https://cygwin.com/pub/cygwin/x86_64/ timestamps, and download sha512.sum, setup.ini.sig, setup.xz.sig, setup.xz to check whether calm has updated every package as expected, checksums, and signatures, and it is okay to announce, using curl -I and a filter: checking setup status https://cygwin.com/pub/cygwin/x86_64/sha512.sum: last-modified: Wed, 24 Jul 2024 15:14:03 GMT content-length: 1278 checking setup status https://cygwin.com/pub/cygwin/x86_64/setup.ini: last-modified: Sat, 27 Jul 2024 21:56:02 GMT content-length: 18169373 content-type: text/plain; charset=UTF-8 -- 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] ca-certificates-letsencrypt maintainer
On 2024-07-14 13:46, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: Re-installed last ca-certificates-letencrypt package and cygport announce and git send-email are working again. Then keep it installed one or two months longer, but I will not revive that package. The original problem with the R3 cross-signed through X3 went away at least a year ago already and the last R3 signed certificates (that don't have this problem) should expire somewhere in the next two or three months latest. New certificates should be signed by R10 or R11 already. Sorry Achim, But given that the Cygwin certs appear that they may require some of these, and does not expire until mid-August, might it not have been better to keep the package around until after then? Some unexpired letsencrypt certificates should probably have been migrated to ca-certificates or left in ca-certificates-letencrypt? Nope. so were any DigiCert certs harmed in the making of this package? ;^> Bollocks. If installing ca-certificates-letencrypt fixes it for you, then it's either an old TrustID X3 or Let's Encrypt R3 certificate (probably the latter) somewhere in the cert chain _plus_ an openssl earlier than 1.2 (as these had a bug in cert validation that gets triggered during validation of a cross-signed a CA). I do not know how to figure out what is in these cert packages, and what correlation is significant between those, my email server, cygwin/sourceware email server, cygport pkg_upload(__pkg_announce) and git send-email. Anyway, the current openssl has no problems with either of the servers you mentioned: It seems to me that both /usr/share/cygport/lib/pkg_upload.cygpart __pkg_announce() and /usr/libexec/git-core/git-send-email send_message() have Net::SMTP::SSL in common: those perl modules and dependencies all seem to be 5.36, and I have no idea how they link to OpenSSL, but could they eventually link to the old OpenSSL 1.1.1w, and could that be causing an issue? -- 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] ca-certificates-letsencrypt maintainer
On 2024-07-14 11:05, Brian Inglis via Cygwin-apps wrote: On 2024-07-13 15:03, Brian Inglis wrote: On 2024-07-13 14:43, Brian Inglis via Cygwin-apps wrote: On 2024-06-30 05:31, ASSI wrote: The following packages have been uploaded to the Cygwin distribution: ca-certificates-2024.2.66_v8.0.302-1 The ca-certificates-letsencrypt package has been removed, since all signatures using the cross-signed certificate chain for Let's Encrypt root servers have long expired. In other words, the problem this package was solving no longer exists. Hi folks, Any chance a cert may have been dropped inadvertently? Or some other update I or others may have packaged could have messed up email. I can no longer use cygport announce or git send-email via this mail server, but Windows Thunderbird still works! Have any Let's Encrypt Intermediate certs been dropped? While Cygwin uses ISRG Root X1 -> R3 -> Cygwin.com my email provider may use ISRG Root X1 -> R11 -> hover.com - all valid until later this year or much longer - checking if they may use a different email cert chain or CA. Hi folks, Re-installed last ca-certificates-letencrypt package and cygport announce and git send-email are working again. Some unexpired letsencrypt certificates should probably have been migrated to ca-certificates or left in ca-certificates-letencrypt? Trying cygport --debug and git send-email --smtp-debug=1 do not show any cert validation - any ideas how to see what certs are used in email auth? Found an answer for that on https://serverfault.com/questions/131627/how-to-inspect-remote-smtp-servers-tls-certificate/131628#131628 for example: $ openssl s_client -connect mail.example.com:465 which using the correct servers and ports gives the certs in the attached log: DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 -> *.hover.com so were any DigiCert certs harmed in the making of this package? ;^> Current DigiCert CA Root and Intermediate certs are shown in: https://www.digicert.com/kb/digicert-root-certificates.htm I have added some non-packaged CA certs in the past and I can try doing that again if it is required to help? -- 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$ openssl s_client -connect mail.hover.com:465 CONNECTED(0004) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1 verify return:1 depth=0 CN = *.hover.com verify return:1 --- Certificate chain 0 s:CN = *.hover.com i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Jul 14 00:00:00 2024 GMT; NotAfter: Jul 13 23:59:59 2025 GMT 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1 i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Nov 2 12:24:33 2017 GMT; NotAfter: Nov 2 12:24:33 2027 GMT 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT --- Server certificate -BEGIN CERTIFICATE- MIIGIDCCBQigAwIBAgIQAsPHqBLbhyMzxknMGhWz5zANBgkqhkiG9w0BAQsFADBg MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMR8wHQYDVQQDExZSYXBpZFNTTCBUTFMgUlNBIENBIEcx MB4XDTI0MDcxNDAwMDAwMFoXDTI1MDcxMzIzNTk1OVowFjEUMBIGA1UEAwwLKi5o b3Zlci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMbFFzY5dq Qo33T6P4s4cexUVhA+gMflpYyI/gA7betlbL6F7cB8JrDl/C9s4/UAvuG0smZI4a ZrzbogtMcvjyhiV8czywWDibCwyrH7nRRidRxCPbtJcC/utRb+g2gTtnUNAFvqnv Jcc3OPZCEo6mnx3RPHH3RpmfXM3faAHHI9VNwRSK8F9w9JDc5PtW5J7pEdxkat6y +faiuYjqKw53a5kocj+9RQDH5X+0f6fltL1Ed3ehSo7n+qkONMn5SE+iYB2EX/Pt VIIFB1deI7GRis9UU3Tfw9osuCxSz7RzE7I+YOMTRPHyi79ns9WthYTtzbS9Cezu ZtMgIWWu4yrHAgMBAAGjggMeMIIDGjAfBgNVHSMEGDAWgBQM22yCSQ9KZwq4FO56 xEhSiOtWODAdBgNVHQ4EFgQUyuEEPsQ/asGApRPLTUAbr8YkstswIQYDVR0RBBow GIILKi5ob3Zlci5jb22CCWhvdmVyLmNvbTA+BgNVHSAENzA1MDMGBmeBDAECATAp MCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwDgYDVR0P AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA/BgNVHR8E ODA2MDSgMqAwhi5odHRwOi8vY2RwLnJhcGlkc3NsLmNvbS9SYXBpZFNTTFRMU1JT QUNBRzEuY3JsMHYGCCsGAQUFBwEBBGowaDAmBggrBgEFBQcwAYYaaHR0cDovL3N0 YXR1cy5yYXBpZHNzbC5jb20wPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYWNlcnRzLnJh cGlkc3NsLmNvb
[ATTN] ca-certificates-letsencrypt maintainer
On 2024-07-13 15:03, Brian Inglis wrote: On 2024-07-13 14:43, Brian Inglis via Cygwin-apps wrote: On 2024-06-30 05:31, ASSI wrote: The following packages have been uploaded to the Cygwin distribution: ca-certificates-2024.2.66_v8.0.302-1 The ca-certificates-letsencrypt package has been removed, since all signatures using the cross-signed certificate chain for Let's Encrypt root servers have long expired. In other words, the problem this package was solving no longer exists. Hi folks, Any chance a cert may have been dropped inadvertently? Or some other update I or others may have packaged could have messed up email. I can no longer use cygport announce or git send-email via this mail server, but Windows Thunderbird still works! Have any Let's Encrypt Intermediate certs been dropped? While Cygwin uses ISRG Root X1 -> R3 -> Cygwin.com my email provider may use ISRG Root X1 -> R11 -> hover.com - all valid until later this year or much longer - checking if they may use a different email cert chain or CA. Hi folks, Re-installed last ca-certificates-letencrypt package and cygport announce and git send-email are working again. Some unexpired letsencrypt certificates should probably have been migrated to ca-certificates or left in ca-certificates-letencrypt? Trying cygport --debug and git send-email --smtp-debug=1 do not show any cert validation - any ideas how to see what certs are used in email auth? -- 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
New: cmocka 1.1.7 - C unit testing framework
From: "Cygwin cmocka Maintainer" Elegant unit testing framework for C with support for mock objects, derived from Google Cmockery. For more information see the project home page: https://cmocka.org The following packages have been added to the Cygwin distribution: * cmocka-doc1.1.7 * libcmocka-devel 1.1.7 * libcmocka01.1.7 For previous changes see below or read /usr/share/doc/cmocka/ChangeLog after installation: https://git.cryptomilk.org/projects/cmocka.git/tree/ChangeLog?h=cmocka-1.1.7 2023-02-23 1.1.7 - Update ignore list for source tarball generation 2023-02-16 1.1.6 - Added new assert macros to compare 2 double given an epsilon - Added meson build system - Added header with version to TAP13 output - Fixed issues with MSVC - Fixed TAP output for skipped tests - Fixed issue with fail_msg - CMake generated configs for find_package(cmocka) - Documentation improvements 2019-03-28 1.1.5 - Added cmocka_set_skip_filter() 2019-03-28 1.1.4 - Added assert_float(_not)_equal() - Added expect_any_always() - Small bug fixes 2018-09-26 1.1.3 - Fixed subunit output on failures - Do not abort if a test is skipped - Switched to Modern CMake 2018-08-29 1.1.2 - Added function to filter tests (cmocka_set_test_filter) - Added new mocking example (uptime) - Fixed fixture error reporting - Fixed compiler flags detection - Some improvement for API documentation 2016-04-07 1.1.1 - Fixed TAP output - Fixed cmocka on Windows x64 - Fixed xUnit output durations 2016-09-21 1.1.0 - Added support to catch multiple exceptions - Added support to verify call ordering - Added support to pass initial data to test cases - Added will_return_maybe() for ignoring mock returns - Added subtests for groups using TAP output - Added support to write multiple XML files for groups - Improved documentation - Fixed XML output generataion - Fixed Windows builds with VS2015 2015-03-12 1.0.1 - Added a macro for assert_ptr_equal(). - Fixed test_realloc() if 0 size is passed. - Fixed objects packaging bug. - Fixed building with newer gcc versions. 2015-02-16 1.0.0 - Added new test runner with group fixtures. The old runner is deprecated - Added an extensible message output formatter - Added jUnit XML message output - Added subunit message output - Added Test Anything Protocol message output - Added skip() command - Added test_realloc() - Added a cmockery compat header - Fixed a lot of bugs on Windows
Re: [ITP] cmocka required for fortune-mod package update
On 2024-07-14 04:15, Jon Turney wrote: On 13/07/2024 21:10, Brian Inglis via Cygwin-apps wrote: On 2024-07-13 13:28, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: ERROR: package 'fortune-mod-src' version '3.22.0-1' build-depends: 'cmocka', but nothing satisfies that ERROR: error while validating merged x86_64 packages for Brian Inglis SUMMARY: 2 ERROR(s) Sorry, I forget to add cmocka to your packages. Done now. Thanks Jon, I will redo that !ready. -- 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: ca-certificates-2024.2.66_v8.0.302-1
On 2024-07-13 14:43, Brian Inglis via Cygwin-apps wrote: On 2024-06-30 05:31, ASSI wrote: The following packages have been uploaded to the Cygwin distribution: ca-certificates-2024.2.66_v8.0.302-1 The ca-certificates-letsencrypt package has been removed, since all signatures using the cross-signed certificate chain for Let's Encrypt root servers have long expired. In other words, the problem this package was solving no longer exists. Hi folks, Any chance a cert may have been dropped inadvertently? Or some other update I or others may have packaged could have messed up email. I can no longer use cygport announce or git send-email via this mail server, but Windows Thunderbird still works! Have any Let's Encrypt Intermediate certs been dropped? While Cygwin uses ISRG Root X1 -> R3 -> Cygwin.com my email provider may use ISRG Root X1 -> R11 -> hover.com - all valid until later this year or much longer - checking if they may use a different email cert chain or CA. -- 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: ca-certificates-2024.2.66_v8.0.302-1
On 2024-06-30 05:31, ASSI wrote: The following packages have been uploaded to the Cygwin distribution: ca-certificates-2024.2.66_v8.0.302-1 The ca-certificates-letsencrypt package has been removed, since all signatures using the cross-signed certificate chain for Let's Encrypt root servers have long expired. In other words, the problem this package was solving no longer exists. Hi folks, Any chance a cert may have been dropped inadvertently? Or some other update I or others may have packaged could have messed up email. I can no longer use cygport announce or git send-email via this mail server, but Windows Thunderbird still works! -- 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: [ITP] cmocka required for fortune-mod package update
On 2024-07-13 13:28, cygwin-no-re...@cygwin.com wrote: ERROR: package 'fortune-mod-src' version '3.22.0-1' build-depends: 'cmocka', but nothing satisfies that ERROR: error while validating merged x86_64 packages for Brian Inglis SUMMARY: 2 ERROR(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
[ITP] cmocka 1.1.7 - C unit testing framework
Description:
Elegant unit testing framework for C with support for mock objects,
derived from Google Cmockery.
License:Apache-2.0
I would like to provide a Cygwin package for cmocka, as it is now
required for testing my fortune-mod package.
For more information see the project home pages:
https://cmocka.org
It is packaged by major Linux and BSD distros:
https://repology.org/project/cmocka/versions
There is an error building the docs using doxygen, and that hangs, using
either cmake/make or cmake/ninja builds, locally and in GH CI (see
previous job 8341 - had to cancel after 3 hours), with current stable and a
local build of the latest doxygen release, and an issue has been raised upstream.
For now, there is little justification to split into dll (40KB 1 file),
devel (100KB 8 files 2 dirs), doc (24KB 4 files 1 dir) packages, unless
for conformity, but can revisit if I can get docs built!
Locally all tests pass (see attached log), but under GH CI 3/48 fail for
some reason.
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=playground&id=49dc54feb8656bfb799d5e03862e093f01888e5d
package job (without docs):
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=playground&user=Brian+Inglis&id=8342
log at:
https://github.com/cygwin/scallywag/actions/runs/9863279238/job/27235896049
For previous changes see below or read /usr/share/doc/cmocka/ChangeLog
after installation:
https://git.cryptomilk.org/projects/cmocka.git/tree/ChangeLog?h=cmocka-1.1.7
2023-02-23 1.1.7
- Update ignore list for source tarball generation
2023-02-16 1.1.6
- Added new assert macros to compare 2 double given an epsilon
- Added meson build system
- Added header with version to TAP13 output
- Fixed issues with MSVC
- Fixed TAP output for skipped tests
- Fixed issue with fail_msg
- CMake generated configs for find_package(cmocka)
- Documentation improvements
2019-03-28 1.1.5
- Added cmocka_set_skip_filter()
2019-03-28 1.1.4
- Added assert_float(_not)_equal()
- Added expect_any_always()
- Small bug fixes
2018-09-26 1.1.3
- Fixed subunit output on failures
- Do not abort if a test is skipped
- Switched to Modern CMake
2018-08-29 1.1.2
- Added function to filter tests (cmocka_set_test_filter)
- Added new mocking example (uptime)
- Fixed fixture error reporting
- Fixed compiler flags detection
- Some improvement for API documentation
2016-04-07 1.1.1
- Fixed TAP output
- Fixed cmocka on Windows x64
- Fixed xUnit output durations
2016-09-21 1.1.0
- Added support to catch multiple exceptions
- Added support to verify call ordering
- Added support to pass initial data to test cases
- Added will_return_maybe() for ignoring mock returns
- Added subtests for groups using TAP output
- Added support to write multiple XML files for groups
- Improved documentation
- Fixed XML output generataion
- Fixed Windows builds with VS2015
2015-03-12 1.0.1
- Added a macro for assert_ptr_equal().
- Fixed test_realloc() if 0 size is passed.
- Fixed objects packaging bug.
- Fixed building with newer gcc versions.
2015-02-16 1.0.0
- Added new test runner with group fixtures. The old runner is deprecated
- Added an extensible message output formatter
- Added jUnit XML message output
- Added subunit message output
- Added Test Anything Protocol message output
- Added skip() command
- Added test_realloc()
- Added a cmockery compat header
- Fixed a lot of bugs on Windows
#|/usr/bin/cygport
# cmocka.cygport - cmocka Cygwin package build control script definitions
# converted by rpmspec2cygport.sh 1.3 2024-07-06 19:50:40+
NAME=cmocka
VERSION=1.1.7
RELEASE=1
CATEGORY="Devel"
SUMMARY="C unit testing framework"
DESCRIPTION="Elegant unit testing framework for C with support for mock objects,
derived from Google Cmockery."
HOMEPAGE=https://cmocka.org
SRC_URI=$HOMEPAGE/files/${VERSION%.*}/$NAME-$VERSION.tar.xz
SRC_URI+=" $SRC_URI.asc"
PATCH_URI=cmocka-1.1.7-doc-Cmakelists-txt-DOXYGEN_PREDEFINED-quote-parens.patch
# cmocka-1.1.7-doc-Cmakelists-txt-DOXYGEN_PREDEFINED.patch
DIFF_EXCLUDES=compile_commands.json
BUILD_REQUIRES="cygwin-devel cmake doxygen gcc-core gnupg2 graphviz"
inherit cmake
CYGCMAKE_ARGS="
-DWITH_CMOCKERY_SUPPORT=ON
-DUNIT_TESTING=ON
"
#PKG_NAMES="libcmocka libcmocka-devel cmocka-doc"
src_compile() {
cd $B
: ${CYGCMAKE_GENERATOR:=Ninja}
# : ${CYGCMAKE_GENERATOR:=Unix Makefiles}
cygcmake
if [ -f build.ninja ]
then
cygninja
# cygninja docs
else
cygmake
# cygmake docs
fi
}
src_test() {
cd $B
if [ -f build.ninja ]
then
sed_ct='/^\(check\|test\):\sphony$/!d;s!!\1!'
ct=$(cygninja -t targets depth 1 | sed -e "$sed_ct")
[ "test" = "$ct" ] && ninja_test || cygninja $ct
else
ctest -V --output-on-failure
fi
}
LICENSE="Apache-2.0"
# SPDX-License-Identifier: Apache-2.0
LICENSE_SPDX="SPDX-License-Id
Re: [ITP] lesspipe 2.13 - less pager input file preprocessor
On 2024-06-29 07:19, Jon Turney via Cygwin-apps wrote: On 26/06/2024 05:49, Brian Inglis via Cygwin-apps wrote: Inadvertently uploaded test instead of prod build of lesspipe. Running untest promoted it from test to (only) current stable. But package source and summary web pages still show the release as in test. Looks like untest action should force a rebuild of the package source and summary web pages. "should" but "does not" currently... 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
Re: [ITP] lesspipe 2.13 - less pager input file preprocessor
On 2024-06-23 14:12, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 08:01, Jon Turney via Cygwin-apps wrote:
On 15/06/2024 16:11, Brian Inglis via Cygwin-apps wrote:
[Forgot attachments]
On 2024-06-14 23:22, Brian Inglis via Cygwin-apps wrote:
I would like to provide a Cygwin package for lesspipe, to automatically
show archive contents or information about many file types, with
enhanced or coloured output, without having to remember which filter
commands are required to do so, as I have been using it for many years.
Thanks, I added this to your packages.
Thanks Jon
src_compile() {
cd $S
# cygautoreconf
What value does this comment have?
lndirs
cd $B
# cygconf
Ditto.
./configure --prefix=/usr
cygmake
}
src_install() {
cd $B
# install -D "${srcdir}"/lesspipe.sh "${pkgdir}"/etc/profile.d/lesspipe.sh
# verbose cp lesspipe.sh $C/profile.d.sh
# In bash, please preload the completion, dynamic invocation does not work
# . /usr/share/bash-completion/less_completion
# Or consider installing the file less_completion in /etc/bashcompletion.d [sic]
dodir /etc/bash_completion.d
insinto /etc/bash_completion.d
doins less_completion
cyginstall
verbose rm -f $D/usr/share/bash-completion/less_completion
It seems like this might be more clearly sequenced:
* do standard install
* comment about the following steps
* remove completion file from non-working location
* install completion file in working location
or could the completion file just be moved post-install, from ${D}
/usr/share/bash-completion/ to ${D}/etc/bash_completion.d/ ?
These are all working copies for playground builds with original and
intermediate commands and notes from install scripts and messages.
I will clean up before merging into master and building a release.
Hi folks/Jon,
Inadvertently uploaded test instead of prod build of lesspipe.
Running untest promoted it from test to (only) current stable.
But package source and summary web pages still show the release as in test.
Looks like untest action should force a rebuild of the package source and
summary web pages.
--
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 2024-06-24 16:23, Marco Atzeri via Cygwin-apps wrote: On 26/11/2023 15:40, Jon Turney via Cygwin-apps wrote: On 21/11/2023 06: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 I think this is the correct patch, so I'll probably apply this. But yeah, I think gpg2 obsoleting gpg, with compatibility symlinks is probably the right thing to do. I will implement this in the next 2.4.5 the current test version seems also able to correctly contact keyservers. That was a problem on latest gpg2 package Yay! At last. That has been frustrating as I have been tweaking my keyserver configs in the hopes of getting the latest keys accepted for my package sources, other downloads, and scripts. I might be able to update and willing to adopt libxslt if all our gpg updates hang together. -- 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: libgpg-error maintainer
On 2024-06-24 14:52, Marco Atzeri via Cygwin-apps wrote:
On 24/06/2024 20:04, Brian Inglis via Cygwin-apps wrote:
On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote:
On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote:
On 23/06/2024 22:13, Marco Atzeri wrote:
On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote:
Update to current needed to update libgcrypt if you could please oblige?
unfortunately any recent version up to 1.50 are failing a lot of tests
PASS: t-version.exe
PASS: t-strerror.exe
fopen failed with bad code: 20
PASS: t-syserror.exe
FAIL: t-lock.exe
FAIL: t-printf.exe
FAIL: t-poll.exe
FAIL: t-b64.exe
FAIL: t-argparse.exe
FAIL: t-logging.exe
PASS: t-stringutils.exe
PASS: t-malloc.exe
===
6 of 11 tests failed
I was never able to find a solution, so if any one can look and give any
suggestion, I will appreciate
regards
Marco
I just rebuilt the old 1.37 and it is reporting the same errors,
while in 2020 it was passing all the tests
so it seems something else is playing a role here
very puzzling
Hi Marco,
I noticed that the build is generating libtool wrapper sources,
executables, and shell scripts under .../build/tests/.libs/ for the test
programs, so if that also happens with 1.37, that raises my suspicions that
what is failing is something to do with those wrappers and Cygwin libtool
mods.
Another possibility is that the failures are caused by a Cygwin bug
introduced since 2020. There have been several bugs in Cygwin 3.5.3 that
have been fixed. Since 3.5.4 hasn't been released yet, you could try the
latest test release of 3.6, which has all the bug fixes.
FWIW, I tried running t-lock.exe under strace and saw "SetThreadName:
SetThreadDescription() failed", followed quickly by a SIGSEGV. That again
suggests a possible Cygwin bug.
Thanks Ken,
Great suggestion - also did strace on t-printf from 1.50 tests/.libs with
src/.libs in the path to pick up test dll and got a loop due to a SEGV on
0005 - makes interesting reading, but does not mean much to me -
terminated it eventually.
Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized.
However, I see no changes since to SetThread related stuff since
misc_funcs.cc in 2022.
There may be some issues with Windows error or exception handling, so I will
retry under cygwin... 3.6.0-115...
No changes after upgrading all cygwin... packages to test 3.6.0-139...
including also taking the precaution of running:
$ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf
...
$ head /proc/version
CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64
(runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC
So perhaps the SetThreadDescription stuff needs another look?
Anyone familiar with that?
Ken, Brian,
it seems it was much simpler.
For some strange reason the HAVE_WEAK_SYMBOLS was defined.
Forcing it off
CYGCONF_ARGS="--disable-languages gl_cv_have_weak=no"
solved almost all errors
I just upload a 1.50 test version were the errors are down to 1
PASS: t-strerror.exe
fopen failed with bad code: 20
FAIL: t-syserror.exe
PASS: t-lock.exe
PASS: t-printf.exe
PASS: t-poll.exe
PASS: t-b64.exe
..
PASS: t-argparse.exe
PASS: t-logging.exe
PASS: t-stringutils.exe
PASS: t-malloc.exe
===
1 of 11 tests failed
let me know if libgcrypt can be built
Thanks Marco,
Great catch!
All tests pass for both libgpg-error 1.50 and libgcrypt: see attached logs.
I installed both locally and interactive tests of gpg{,v}{,2} all pass.
I fetched the latest Cygwin pubkey as I was getting warnings from my scripts,
and they are now all quiet.
So I am now dogfooding those two until your libgpg-error is officially updated,
then I can officially update my libgcrypt!
I made some tweaks to your libgpg-error cygport just in case something helped
with the issue.
I impertinently pushed some changes to your libgpg-error playground build to see
if there were any differences in there.
Please have a look at the manifest patch and cygport updates in the libgpg-error
playground branch and jobs.
My tweaked cygport seems to have passed there also; please see:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libgpg-error
I have no idea what may have made the difference.
I updated the URIs, patched the manifest for W10, updated bld-req, added -cygwin
to config PACKAGE_VERSION, added reproducible build timestamp, commented out
test function override, added licence?
I am also adding -cygwin to config PACKAGE_VERSION and reproducible build
timestamp to libgcrypt (based on origsrc/.../ChangeLog as that seems consistent
across packages: whereas src ChangeLog and other files seem to be copied or
could be patched by us)!
--
Take c
Re: libgpg-error allocation stack corruption
On 2024-06-24 12:04, Brian Inglis via Cygwin-apps wrote:
On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote:
On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote:
On 23/06/2024 22:13, Marco Atzeri wrote:
On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote:
Update to current needed to update libgcrypt if you could please oblige?
unfortunately any recent version up to 1.50 are failing a lot of tests
PASS: t-version.exe
PASS: t-strerror.exe
fopen failed with bad code: 20
PASS: t-syserror.exe
FAIL: t-lock.exe
FAIL: t-printf.exe
FAIL: t-poll.exe
FAIL: t-b64.exe
FAIL: t-argparse.exe
FAIL: t-logging.exe
PASS: t-stringutils.exe
PASS: t-malloc.exe
===
6 of 11 tests failed
I was never able to find a solution, so if any one can look and give any
suggestion, I will appreciate
regards
Marco
I just rebuilt the old 1.37 and it is reporting the same errors,
while in 2020 it was passing all the tests
so it seems something else is playing a role here
very puzzling
Hi Marco,
I noticed that the build is generating libtool wrapper sources, executables,
and shell scripts under .../build/tests/.libs/ for the test programs, so if
that also happens with 1.37, that raises my suspicions that what is failing
is something to do with those wrappers and Cygwin libtool mods.
Another possibility is that the failures are caused by a Cygwin bug
introduced since 2020. There have been several bugs in Cygwin 3.5.3 that
have been fixed. Since 3.5.4 hasn't been released yet, you could try the
latest test release of 3.6, which has all the bug fixes.
FWIW, I tried running t-lock.exe under strace and saw "SetThreadName:
SetThreadDescription() failed", followed quickly by a SIGSEGV. That again
suggests a possible Cygwin bug.
Thanks Ken,
Great suggestion - also did strace on t-printf from 1.50 tests/.libs with
src/.libs in the path to pick up test dll and got a loop due to a SEGV on
0005 - makes interesting reading, but does not mean much to me -
terminated it eventually.
Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized.
However, I see no changes since to SetThread related stuff since misc_funcs.cc
in 2022.
There may be some issues with Windows error or exception handling, so I will
retry under cygwin... 3.6.0-115...
No changes after upgrading all cygwin... packages to test 3.6.0-139... including
also taking the precaution of running:
$ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf
...
$ head /proc/version
CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64
(runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC
So perhaps the SetThreadDescription stuff needs another look?
Anyone familiar with that?
I cut down various parts of the program, and finally narrowed it down to gpgrt
allocation or cygwin allocation corrupting the stack so return fails.
See attached gdb log.
--
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éryone_test_x0 (format=format@entry=0x10040518e "%d %% %d") at stc-t-printf.c:101
101 if (one_test_rc1 == -1)
(gdb)
107 show (" sys: ->%s<-\n", one_test_buf1);
(gdb)
0x000100401087 in show (format=format@entry=0x10040505c " sys: ->%s<-\n")
at /usr/src/debug/libgpg-error-1.50-1/tests/t-common.h:119
119 /usr/src/debug/libgpg-error-1.50-1/tests/t-common.h: No such file or
directory.
(gdb)
122 in /usr/src/debug/libgpg-error-1.50-1/tests/t-common.h
(gdb)
run_tests () at stc-t-printf.c:201
201 one_test_2 ("%d %% %d", 17, 768114563);
(gdb)
0x00010040142d in one_test_x1 (format=format@entry=0x10040518e "%d %% %d")
at stc-t-printf.c:112
112 {
(gdb)
117 errno = ENOENT;
(gdb)
__errno () at
/usr/src/debug/cygwin-3.6.0-0.139.g7e3c833592b2/newlib/libc/errno/errno.c:17
17return &_REENT_ERRNO(_REENT);
(gdb)
__getreent () at
/usr/src/debug/cygwin-3.6.0-0.139.g7e3c833592b2/winsup/cygwin/include/cygwin/config.h:40
40__asm __volatile__ ("movq %%gs:8,%0" : "=r" (ret));
(gdb)
__errno () at
/usr/src/debug/cygwin-3.6.0-0.139.g7e3c833592b2/winsup/cygwin/include/cygwin/config.h:44
44return (struct _reent *) (ret - __CYGTLS_PADSIZE__);
(gdb)
one_test_x1 (format=format@entry=0x10040518e "%d %% %d") at stc-t-printf.c:118
118 va_start (arg_ptr, format);
(gdb)
119 rc2 = gpgrt_vasprintf (&buf2, format, arg_ptr);
(gdb)
gpgrt_vaspri
Re: Attn: libgpg-error maintainer
On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote: On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote: On 23/06/2024 22:13, Marco Atzeri wrote: On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote: Update to current needed to update libgcrypt if you could please oblige? unfortunately any recent version up to 1.50 are failing a lot of tests PASS: t-version.exe PASS: t-strerror.exe fopen failed with bad code: 20 PASS: t-syserror.exe FAIL: t-lock.exe FAIL: t-printf.exe FAIL: t-poll.exe FAIL: t-b64.exe FAIL: t-argparse.exe FAIL: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 6 of 11 tests failed I was never able to find a solution, so if any one can look and give any suggestion, I will appreciate regards Marco I just rebuilt the old 1.37 and it is reporting the same errors, while in 2020 it was passing all the tests so it seems something else is playing a role here very puzzling Hi Marco, I noticed that the build is generating libtool wrapper sources, executables, and shell scripts under .../build/tests/.libs/ for the test programs, so if that also happens with 1.37, that raises my suspicions that what is failing is something to do with those wrappers and Cygwin libtool mods. Another possibility is that the failures are caused by a Cygwin bug introduced since 2020. There have been several bugs in Cygwin 3.5.3 that have been fixed. Since 3.5.4 hasn't been released yet, you could try the latest test release of 3.6, which has all the bug fixes. FWIW, I tried running t-lock.exe under strace and saw "SetThreadName: SetThreadDescription() failed", followed quickly by a SIGSEGV. That again suggests a possible Cygwin bug. Thanks Ken, Great suggestion - also did strace on t-printf from 1.50 tests/.libs with src/.libs in the path to pick up test dll and got a loop due to a SEGV on 0005 - makes interesting reading, but does not mean much to me - terminated it eventually. Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized. However, I see no changes since to SetThread related stuff since misc_funcs.cc in 2022. There may be some issues with Windows error or exception handling, so I will retry under cygwin... 3.6.0-115... No changes after upgrading all cygwin... packages to test 3.6.0-139... including also taking the precaution of running: $ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf ... $ head /proc/version CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64 (runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC So perhaps the SetThreadDescription stuff needs another look? Anyone familiar with that? -- 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: libgpg-error maintainer
On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote: On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote: On 23/06/2024 22:13, Marco Atzeri wrote: On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote: Update to current needed to update libgcrypt if you could please oblige? unfortunately any recent version up to 1.50 are failing a lot of tests PASS: t-version.exe PASS: t-strerror.exe fopen failed with bad code: 20 PASS: t-syserror.exe FAIL: t-lock.exe FAIL: t-printf.exe FAIL: t-poll.exe FAIL: t-b64.exe FAIL: t-argparse.exe FAIL: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 6 of 11 tests failed I was never able to find a solution, so if any one can look and give any suggestion, I will appreciate regards Marco I just rebuilt the old 1.37 and it is reporting the same errors, while in 2020 it was passing all the tests so it seems something else is playing a role here very puzzling Hi Marco, I noticed that the build is generating libtool wrapper sources, executables, and shell scripts under .../build/tests/.libs/ for the test programs, so if that also happens with 1.37, that raises my suspicions that what is failing is something to do with those wrappers and Cygwin libtool mods. Another possibility is that the failures are caused by a Cygwin bug introduced since 2020. There have been several bugs in Cygwin 3.5.3 that have been fixed. Since 3.5.4 hasn't been released yet, you could try the latest test release of 3.6, which has all the bug fixes. FWIW, I tried running t-lock.exe under strace and saw "SetThreadName: SetThreadDescription() failed", followed quickly by a SIGSEGV. That again suggests a possible Cygwin bug. Thanks Ken, Great suggestion - also did strace on t-printf from 1.50 tests/.libs with src/.libs in the path to pick up test dll and got a loop due to a SEGV on 0005 - makes interesting reading, but does not mean much to me - terminated it eventually. Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized. However, I see no changes since to SetThread related stuff since misc_funcs.cc in 2022. There may be some issues with Windows error or exception handling, so I will retry under cygwin... 3.6.0-115... -- 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 --- Process 3172 created --- Process 3172 loaded C:/Windows/System32/ntdll.dll at 7ffb4b91 --- Process 3172 loaded C:/Windows/System32/kernel32.dll at 7ffb4b10 --- Process 3172 loaded C:/Windows/System32/KernelBase.dll at 7ffb490c --- Process 3172 thread 11960 created --- Process 3172 thread 2668 created --- Process 3172 loaded C:/.../cygwin64/usr/src/libgpg-error/libgpg-error-1.50-1.x86_64/build/src/.libs/cyggpg-error-0.dll at 00048825 --- Process 3172 thread 10200 created --- Process 3172 loaded C:/.../cygwin64/bin/cygwin1.dll at 7ffb34d2 --- Process 3172 loaded C:/.../cygwin64/bin/cygintl-8.dll at 0005ee2d --- Process 3172 loaded C:/.../cygwin64/bin/cygiconv-2.dll at 00038e6a 0 0 [main] t-printf (3172) ** 11071107 [main] t-printf (3172) Program name: C:/.../cygwin64/usr/src/libgpg-error/libgpg-error-1.50-1.x86_64/build/tests/.libs/t-printf.exe (windows pid 3172) 2761383 [main] t-printf (3172) OS version: Windows NT-10.0 3711754 [main] t-printf (3172) ** --- Process 3172 loaded C:/Windows/System32/advapi32.dll at 7ffb4b05 --- Process 3172 loaded C:/Windows/System32/msvcrt.dll at 7ffb4aa6 --- Process 3172 loaded C:/Windows/System32/sechost.dll at 7ffb4b7c --- Process 3172 loaded C:/Windows/System32/rpcrt4.dll at 7ffb4ad8 --- Process 3172 loaded C:/Windows/System32/bcrypt.dll at 7ffb4991 --- Process 3172 loaded C:/Windows/System32/cryptbase.dll at 7ffb4824 --- Process 3172 loaded C:/Windows/System32/bcryptprimitives.dll at 7ffb494c 13779 15533 [main] t-printf (3172) sigprocmask: 0 = sigprocmask (0, 0x0, 0x7FFB35004370) 22527 38060 [main] t-printf (3172) open_shared: name shared.5, shared 0x1A000 (wanted 0x1A000), h 0x128, m 0, created 0 725 38785 [main] t-printf (3172) user_heap_info::init: heap base 0xA, heap top 0xA, heap size 0x2000 (536870912) 432 39217 [main] t-printf (3172) open_shared: name S-1-5-21-3709023027-2347157756-1758867846-1001.1, shared 0x1A001 (wanted 0x1A001), h 0x124, m 1, created 0 212 39429 [main] t-printf (31
Re: Attn: libgpg-error maintainer
On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote: On 23/06/2024 22:13, Marco Atzeri wrote: On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote: Update to current needed to update libgcrypt if you could please oblige? unfortunately any recent version up to 1.50 are failing a lot of tests PASS: t-version.exe PASS: t-strerror.exe fopen failed with bad code: 20 PASS: t-syserror.exe FAIL: t-lock.exe FAIL: t-printf.exe FAIL: t-poll.exe FAIL: t-b64.exe FAIL: t-argparse.exe FAIL: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 6 of 11 tests failed I was never able to find a solution, so if any one can look and give any suggestion, I will appreciate regards Marco I just rebuilt the old 1.37 and it is reporting the same errors, while in 2020 it was passing all the tests so it seems something else is playing a role here very puzzling Hi Marco, I noticed that the build is generating libtool wrapper sources, executables, and shell scripts under .../build/tests/.libs/ for the test programs, so if that also happens with 1.37, that raises my suspicions that what is failing is something to do with those wrappers and Cygwin libtool mods. -- 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: [ITP] lesspipe 2.13 - less pager input file preprocessor
On 2024-06-23 08:01, Jon Turney via Cygwin-apps wrote:
On 15/06/2024 16:11, Brian Inglis via Cygwin-apps wrote:
[Forgot attachments]
On 2024-06-14 23:22, Brian Inglis via Cygwin-apps wrote:
I would like to provide a Cygwin package for lesspipe, to automatically
show archive contents or information about many file types, with
enhanced or coloured output, without having to remember which filter
commands are required to do so, as I have been using it for many years.
Thanks, I added this to your packages.
Thanks Jon
src_compile() {
cd $S
# cygautoreconf
What value does this comment have?
lndirs
cd $B
# cygconf
Ditto.
./configure --prefix=/usr
cygmake
}
src_install() {
cd $B
# install -D "${srcdir}"/lesspipe.sh "${pkgdir}"/etc/profile.d/lesspipe.sh
# verbose cp lesspipe.sh $C/profile.d.sh
# In bash, please preload the completion, dynamic invocation does not work
# . /usr/share/bash-completion/less_completion
# Or consider installing the file less_completion in /etc/bashcompletion.d [sic]
dodir /etc/bash_completion.d
insinto /etc/bash_completion.d
doins less_completion
cyginstall
verbose rm -f $D/usr/share/bash-completion/less_completion
It seems like this might be more clearly sequenced:
* do standard install
* comment about the following steps
* remove completion file from non-working location
* install completion file in working location
or could the completion file just be moved post-install, from ${D}
/usr/share/bash-completion/ to ${D}/etc/bash_completion.d/ ?
These are all working copies for playground builds with original and
intermediate commands and notes from install scripts and messages.
I will clean up before merging into master and building a 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: [ITP] python-license-expression and cygport PoC patch
On 2024-06-23 08:26, Jon Turney via Cygwin-apps wrote: On 06/06/2024 20:03, Brian Inglis via Cygwin-apps wrote: I found github/nexB/license-expression Python package to do SPDX licence checks developed by the same team doing SPDX-toolkit for SPDX, using the same current data, by and working with Fedora folks et al. Thanks for taking a look at this problem. Having a package for this seems fine, but: this package is what calm uses, and still has the drawbacks I mentioned: * embeds the SPDX license data, doesn't dynamically fetch it * can't really handle LicenseRef reasonably Thanks Jon, They appear to be looking at splitting the code and data packages, as the rules appear to be settling down somewhat, whereas the data will only expand, and they seem to want to make it easier to keep up the release cadence. [But looking back at zoneinfo tzdb packages tzcode and tzdata: they used to be split, are still are logically, but every release now happens to both simultaneously, and for our distro, it makes no sense to not release tzcode, including the utilities, with tzdata, as that way we always pick up the latest tweaks.] Given the trapping problems you solved below, it should be possible in the SPDX instantiation, to trap the unpackaged LicenseRef-* and ExceptionRef-* entries and downgrade their reporting to warnings. [I do not agree with their packaging of ...Refs based on the reporting or requesting organization, for example, ScanCode, Fedora, etc. rather than the package source, for example, I use LicenseRef-IANA-TZ-Public-Domain rather than something like LicenseRef-ScanCode-Public-Domain, and they only allow ExceptionRefs after WITH even when, for example, Google grants IP rights in addition to those in the licence, tying both together, so they are *NOT* independent. Having raised a few issues and made a few points about various public domain packages and licences, SPDX appear to be fixated on licence texts as the embodiment of each variety of public domain licence, despite there probably only being a few major sources: expired copyrights (coming up for really ancient sources), US government department sources, and individual US developers; there may be occasional non-US individual developers, but as there is no real public domain concept elsewhere, they have often come up with equivalent expressions, like WTFPL, etc.] I also am not sure we want to have to jump thru SPDX hoops for each Cygwin package licence we hit before Fedora does? Successful attempt to package Python license-expression (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210 log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a 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'm not super-keen on adding a cygport dependency on python, just to do this check. It would probably be preferable to do this check initially after the .cygport is read, rather than only telling you about problems when you get around to doing to the package step. Add after the mandatory variables checks for LICENSE, etc.? Could be optional additional packages - install python-SPDX-licen[cs]e-expression package which depends on python-license-expression to do checks - cygport checks for SPDX and runs licence checks only if present? 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 fully. Yeah, the way validate() handles parse errors is bizarre and unhelpful. What I ended up doing is calling parse() first to catch those errors, so something like: try: licensing.parse(expression) errs = licensing.validate(expression).errors except (ExpressionError, ExpressionParseError) as e: print(e, file=sys.stderr) return 2 Thanks for that tip, I will have another look at calm, and see if I can work on adding that, also checking for ...Refs, and warning or erroring (non-fatal) as appropriate, in python-SPDX-license-expression. Then another approach early in cygport to detect and check. -- 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
Attn: libgpg-error maintainer
Update to current needed to update libgcrypt if you could please oblige? -- 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] ctags 6.1.0 - programming language source indexing and cross-reference tool
On 2024-06-17 09:40, Jon Turney via Cygwin-apps wrote:
On 15/06/2024 16:10, Brian Inglis via Cygwin-apps wrote:
[Forgot attachments]
On 2024-06-14 23:20, Brian Inglis via Cygwin-apps wrote:
I would like to adopt ctags and update it to successor universal-ctags.
Thanks. I added this to your packages.
Thanks Jon once again
> This should say "universal-ctags", right?
This was directly converted from Fedora Rawhide spec, my normal approach to
adding or adopting and upgrading packages available in Fedora.
None of the other descriptions in distros (Debian, OpenSuSE) were any better,
nor were the source README.md, man page, or home page.
Description:
Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of
language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming.
Rereading, that could be confusing, I'll pull up the variety of descriptions in
editor windows and see if I can pull together a better description for the
released version, including a wee bit more of the history about the connections.
--
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: [ITP] python-license-expression 30.3.0 - Python license expression utility library
[Forgot attachments]
On 2024-06-14 23:25, Brian Inglis via Cygwin-apps wrote:
I would like to provide a Cygwin package for license-expression Python
package to do SPDX licence checks, developed by the same team doing
SPDX-toolkit for SPDX, using the same current data, by and working with
Fedora folks et al.
Description:
Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions).
License:Apache-2.0
For more information see the project home pages:
https://github.com/nexB/license-expression
https://pypi.org/project/license-expression
It is in PyPI and packaged by major Linux and BSD distros, and Msys2:
https://repology.org/project/python:license-expression/versions
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a
package job (without tests):
https://cygwin.com/cgi-bin2/jobs.cgi?id=8210&srcpkg=playground&user=Brian+Inglis
log at:
https://github.com/cygwin/scallywag/actions/runs/9293093201
The package installs and runs using PoC script attached in
spdx-license-expression.py hooked into /usr/share/cygport/lib/pkg_pkg.cygpart
by the 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 fully.
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!
;^>
Recent changes:
v30.3.0 - 2024-03-18
This is a minor release without API changes:
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.23
- Drop support for Python 3.7
v30.2.0 - 2023-11-29
This is a minor release without API changes:
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.22
- Add Python 3.12 support in CI
v30.1.1 - 2023-01-16
This is a minor dot release without API changes
- Use latest skeleton
- Update license list to latest ScanCode and SPDX 3.20
v30.1.0 - 2023-01-16
This is a minor release without API changes
- Use latest skeleton (and updated configure script)
- Update license list to latest ScanCode and SPDX 3.19
- Use correct syntax for python_require
- Drop using Travis and Appveyor
- Drop support for Python 3.7 and add Python 3.11 in CI
v30.0.0 - 2022-05-10
This is a minor release with API changes
- Use latest skeleton (and updated configure script)
- Drop using calver
- Improve error checking when combining licenses
--
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
VERSION=30.3.0
RELEASE=1
BASE=${NAME#python-}
CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions)."
ARCH=noarch
LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"
DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"
#!/usr/bin/python
"""spdx-license-expression.py - validate SPDX licence expression
Usage: spdx-license-expression.py
Author: Brian Inglis
"""
from license_expression import get_spdx_licensing
import sys
def main(args):
if len(args) != 1:
print("usage: " + sys.argv[0] + " ",
file=sys.stderr)
return 1
licensing = get_spdx_licensing()
expression = args[0]
errs = licensing.validate(expression).errors
#ExpressionInfo(
# original_expression='... and MIT and GPL-2.0+',
# normalized_expression=None,
# errors=['Unknown license key(s): ...'],
# invalid_symbols=['...']
#)
for e in errs:
print(e, file=sys.stderr)
if len(errs) >= 1:
return 2
if __name__ == "__main__":
sys.exit(main(sy
Re: [ITP] lesspipe 2.13 - less pager input file preprocessor
[Forgot attachments] On 2024-06-14 23:22, Brian Inglis via Cygwin-apps wrote: I would like to provide a Cygwin package for lesspipe, to automatically show archive contents or information about many file types, with enhanced or coloured output, without having to remember which filter commands are required to do so, as I have been using it for many years. Description: Converts many file formats to text with coloured or enhanced display, so their contents or useful information about their contents can be shown. See the less(1) man page section INPUT PREPROCESSOR. The input filter is a bash script, which also works under zsh, and is easily extensible for new formats. Tab completion mechanisms for archive contents are provided for bash and zsh. Also works with git version control, mutt mail client, vim text editor. Can handle a wide variety of file formats, even files compressed and contained in a hierarchy of archives, enabling users to deeply inspect archives, and display the contents of files in archives without having to unpack them. Converters are checked for and used if available, including Cygwin packages: antiwordMS Word files binutilstext strings in binary files or archives brotli compressed files or archives bsdtar archive files bzip2 compressed files or archives cabextract MS Cabinet files catdoc MS Word files cpioarchive files djvulibre DjVu files genisoimage ISO files or images ghostscript PS files groff man pages or Unix source documents gzipcompressed files or archives hdf5HDF v5 files id3v2 media files ImageMagick image files jq JSON data files libiconvcharacter set code page conversion lynxHTML files lz4 compressed files or archives lzipcompressed files or archives mediainfo media files netcdf nc4 NetCDF files odt2txt OpenDocument files openssl Digital Security Certificates p7zip archive files perl-Image-ExifTool media files poppler PDF files python39-pygments program source code files rpm RPM files source-highlightprogram source code files texlive TeX files unrtf RTF files unzip zip files util-linux tabular data files w3m HTML files wordviewMS Office files writerperfect MS Office files wv MS Word files xlsx2csvMS Excel files xz compressed files or archives zstdcompressed files or archives. To use these, select them for install in the Cygwin Setup program. License:GPL-2.0-or-later It may be enabled by running interactively: $ eval `/usr/bin/lesspipe.sh` or adding to a login profile the command: eval $(/usr/bin/lesspipe.sh) For more information see the project home pages: https://www-zeuthen.desy.de/~friebel/unix/lesspipe.html https://github.com/wofr06/lesspipe It is packaged by Arch, FreeBSD, Gentoo, MacPorts, and some minor distros: https://repology.org/project/lesspipe/versions Attached cygport and at: https://cygwin.com/cgit/cygwin-packages/playground/tree/lesspipe.cygport?id=43513a15e256c7203efc0ea18de8202dc16558dc package job: https://cygwin.com/cgi-bin2/jobs.cgi?id=8266&srcpkg=playground&user=Brian+Inglis log at: https://github.com/cygwin/scallywag/actions/runs/9457549487/job/26051697527 There are some test issues, some of which have been patched, some with test data date issues, and others with filter issues which need addressed upstream. For recent changes, see below: 2024-May-10 2.13 - added support for appimage and snap files - respect color scheme setting of vim in vimcolor, add listing of file types - improve xml (and html) display using the xmq binary - fix color detection (-R) again - support for cpio archives - fall back to 7z for supported formats 2024-Mar-18 2.12 - improve completion for file names with special chars - better output when using xlscat - respect bat options from LESSCOLORIZER - propagate lesspipe changes to lesscomplete - don't use antiword any longer, outdated - use 7zip instead of now outdated p7zip if available - propagate file extension to newly created temporary file
Re: [ITA] ctags 6.1.0 - programming language source indexing and cross-reference tool
[Forgot attachments]
On 2024-06-14 23:20, Brian Inglis via Cygwin-apps wrote:
Frank was a contributor to universal-ctags ~2015 but seemed mainly for
Windows and Notepad++ plug in development.
I would like to adopt ctags and update it to successor universal-ctags.
Description:
Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of
language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming.
License:GPL-2.0-or-later
For more info see the project home pages:
https://ctags.io/
https://github.com/universal-ctags/ctags
Packaged by major Linux and BSD distros, MacPorts, and Msys2:
https://repology.org/project/universal-ctags/versions
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/ctags/tree/ctags.cygport?h=playground
package build with a couple of failed tests with known causes:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ctags
log at:
https://github.com/cygwin/scallywag/actions/runs/9399504588
Packaged universal-ctags 6.1 performance was:
Timetagspackage
6s 8MBctags source tree including multi-language test examples
12s 22MBnewlib-cygwin source tree
For changes since the previous Cygwin release see below:
2024-12-28 6.1
New and extended options and their flags
- ``--regex-`` option
- ``{postrun}`` and ``{intervaltab}`` flags are added.
Incompatible changes
- `section` kind is deleted from Asm parser.
Parser related changes
New parsers
The following parsers have been added:
- BibLaTeX *BibTeX based subparser*
- Forth *optlib*
- Quarto: new parser
+ Quarto
- V: new parser
- Terraform: new parser
+ Terraform (HCL) (*.tf): new parser
- TerraformVariables *optlib*
- PkgConfig *optlib*: new parser
- I18nRubyGem *YAML based subparser*
- XRC *libxml*: new parser
Changes about parser specific kinds, roles, fields, and extras
- Asm
+ `section` kind is deleted.
- AutoIt
+ Drop `$` from tags for variables names.
- Automake
+ New extra `canonicalizedName`
+ New kind `pseudodir`
- C
+ New role `foreigndecl` for `function` kind
+ New role `foreigndecl` for `struct` kind
+ New field `section`
+ New field `alias`
- C++
+ New field `section`
+ New field `alias`
- CUDA
+ New field `section`
+ New field `alias`
- Fortran
+ New extra `linkName`.
- JavaScript
+ New role `foreigndecl` for `function` kind
- Kconfig
+ New kind `variable`
- LdScript
+ New role `destination` for `inputSection` kind
+ New role `aliased` for `symbol` kind
- Markdown
+ New kind `hashtag`
- SystemTap
+ New role `attached` for `probe` kind
- SystemVerilog
+ New kind `define`
Readtags
- Enhancement: add `-P, --with-psuedo-tags` option.
- Enhancement: add `-A, --absolute-input` and `-C, --canonicalize-input`
options.
See :ref:`readtags(1) `. for more details.
- Enhancement: add `-d, --debug` option for debugging purpose.
- Bugfix: make `--formatter` options works.
Merged pull requests
- Pull in the latest subtrees
- readtags: add --with-psuedo-tags option
- I18nRubyGem: add a new kind, "locale"
- Ruby: improve the way of parsing `Class.new(SuperClass)`
- XML Based Resource System (XRC): new parser
- I18nRubyGem: new parser
- docs(man): write about guest parsers
- Revise the release process
- PkgConfig: new parser
- rpmMacros: process areas surrounded by pairs of curly bracket
- Vera: revise the dataflow of cppGetc -> vStringPut
- nestlevel: Fix user data alignment
- Cxx: extract section information from __attribute__((section("SECTION")))
- NEWS: merge README.rst and README.md
- builds-sys/test: enhance check-genfile target
- various minor fixes
- GitHub Actions: disable BSD workflows again
- circleci: use fedora39
- misc/news.bash: generalize the script
- docs(web): manage versions of NEWS
- main: use the interval tree for filling scope field
- V for merging
- YACC: fix a typo in the pattern for skipping C strings
- Revise: the way of accessing the optVm's appData
- dsl: extend #/../ operator to be able to extract a matched group in the
pattern
- Docs: minor fixes
- misc/units.py: fix invalid escape
[ITP] python-license-expression 30.3.0 - Python license expression utility library
I would like to provide a Cygwin package for license-expression Python package to do SPDX licence checks, developed by the same team doing SPDX-toolkit for SPDX, using the same current data, by and working with Fedora folks et al. Description: Python utility library to parse, compare, simplify and normalize license expressions (such as SPDX license expressions). License:Apache-2.0 For more information see the project home pages: https://github.com/nexB/license-expression https://pypi.org/project/license-expression It is in PyPI and packaged by major Linux and BSD distros, and Msys2: https://repology.org/project/python:license-expression/versions Attached cygport and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a package job (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210&srcpkg=playground&user=Brian+Inglis log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 The package installs and runs using PoC script attached in spdx-license-expression.py hooked into /usr/share/cygport/lib/pkg_pkg.cygpart by the 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 fully. 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! ;^> Recent changes: v30.3.0 - 2024-03-18 This is a minor release without API changes: - Use latest skeleton - Update license list to latest ScanCode and SPDX 3.23 - Drop support for Python 3.7 v30.2.0 - 2023-11-29 This is a minor release without API changes: - Use latest skeleton - Update license list to latest ScanCode and SPDX 3.22 - Add Python 3.12 support in CI v30.1.1 - 2023-01-16 This is a minor dot release without API changes - Use latest skeleton - Update license list to latest ScanCode and SPDX 3.20 v30.1.0 - 2023-01-16 This is a minor release without API changes - Use latest skeleton (and updated configure script) - Update license list to latest ScanCode and SPDX 3.19 - Use correct syntax for python_require - Drop using Travis and Appveyor - Drop support for Python 3.7 and add Python 3.11 in CI v30.0.0 - 2022-05-10 This is a minor release with API changes - Use latest skeleton (and updated configure script) - Drop using calver - Improve error checking when combining licenses Attached: python-license-expression.cygport spdx-license-expression.py cygport-lib-pkg_pkg-cygpart-spdx-license-expression-check.patch spdx-license-expression-test.log
[ITP] lesspipe 2.13 - less pager input file preprocessor
I would like to provide a Cygwin package for lesspipe, to automatically show archive contents or information about many file types, with enhanced or coloured output, without having to remember which filter commands are required to do so, as I have been using it for many years. Description: Converts many file formats to text with coloured or enhanced display, so their contents or useful information about their contents can be shown. See the less(1) man page section INPUT PREPROCESSOR. The input filter is a bash script, which also works under zsh, and is easily extensible for new formats. Tab completion mechanisms for archive contents are provided for bash and zsh. Also works with git version control, mutt mail client, vim text editor. Can handle a wide variety of file formats, even files compressed and contained in a hierarchy of archives, enabling users to deeply inspect archives, and display the contents of files in archives without having to unpack them. Converters are checked for and used if available, including Cygwin packages: antiwordMS Word files binutilstext strings in binary files or archives brotli compressed files or archives bsdtar archive files bzip2 compressed files or archives cabextract MS Cabinet files catdoc MS Word files cpioarchive files djvulibre DjVu files genisoimage ISO files or images ghostscript PS files groff man pages or Unix source documents gzipcompressed files or archives hdf5HDF v5 files id3v2 media files ImageMagick image files jq JSON data files libiconvcharacter set code page conversion lynxHTML files lz4 compressed files or archives lzipcompressed files or archives mediainfo media files netcdf nc4 NetCDF files odt2txt OpenDocument files openssl Digital Security Certificates p7zip archive files perl-Image-ExifTool media files poppler PDF files python39-pygments program source code files rpm RPM files source-highlightprogram source code files texlive TeX files unrtf RTF files unzip zip files util-linux tabular data files w3m HTML files wordviewMS Office files writerperfect MS Office files wv MS Word files xlsx2csvMS Excel files xz compressed files or archives zstdcompressed files or archives. To use these, select them for install in the Cygwin Setup program. License:GPL-2.0-or-later It may be enabled by running interactively: $ eval `/usr/bin/lesspipe.sh` or adding to a login profile the command: eval $(/usr/bin/lesspipe.sh) For more information see the project home pages: https://www-zeuthen.desy.de/~friebel/unix/lesspipe.html https://github.com/wofr06/lesspipe It is packaged by Arch, FreeBSD, Gentoo, MacPorts, and some minor distros: https://repology.org/project/lesspipe/versions Attached cygport and at: https://cygwin.com/cgit/cygwin-packages/playground/tree/lesspipe.cygport?id=43513a15e256c7203efc0ea18de8202dc16558dc package job: https://cygwin.com/cgi-bin2/jobs.cgi?id=8266&srcpkg=playground&user=Brian+Inglis log at: https://github.com/cygwin/scallywag/actions/runs/9457549487/job/26051697527 There are some test issues, some of which have been patched, some with test data date issues, and others with filter issues which need addressed upstream. For recent changes, see below: 2024-May-10 2.13 - added support for appimage and snap files - respect color scheme setting of vim in vimcolor, add listing of file types - improve xml (and html) display using the xmq binary - fix color detection (-R) again - support for cpio archives - fall back to 7z for supported formats 2024-Mar-18 2.12 - improve completion for file names with special chars - better output when using xlscat - respect bat options from LESSCOLORIZER - propagate lesspipe changes to lesscomplete - don't use antiword any longer, outdated - use 7zip instead of now outdated p7zip if available - propagate file extension to newly created temporary files - use again csvlook for display of csv files if available - use csvtable for tabular display
[ITA] ctags 6.1.0 - programming language source indexing and cross-reference tool
Frank was a contributor to universal-ctags ~2015 but seemed mainly for
Windows and Notepad++ plug in development.
I would like to adopt ctags and update it to successor universal-ctags.
Description:
Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of
language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming.
License:GPL-2.0-or-later
For more info see the project home pages:
https://ctags.io/
https://github.com/universal-ctags/ctags
Packaged by major Linux and BSD distros, MacPorts, and Msys2:
https://repology.org/project/universal-ctags/versions
Attached cygport and at:
https://cygwin.com/cgit/cygwin-packages/ctags/tree/ctags.cygport?h=playground
package build with a couple of failed tests with known causes:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ctags
log at:
https://github.com/cygwin/scallywag/actions/runs/9399504588
Packaged universal-ctags 6.1 performance was:
Timetagspackage
6s 8MBctags source tree including multi-language test examples
12s 22MBnewlib-cygwin source tree
For changes since the previous Cygwin release see below:
2024-12-28 6.1
New and extended options and their flags
- ``--regex-`` option
- ``{postrun}`` and ``{intervaltab}`` flags are added.
Incompatible changes
- `section` kind is deleted from Asm parser.
Parser related changes
New parsers
The following parsers have been added:
- BibLaTeX *BibTeX based subparser*
- Forth *optlib*
- Quarto: new parser
+ Quarto
- V: new parser
- Terraform: new parser
+ Terraform (HCL) (*.tf): new parser
- TerraformVariables *optlib*
- PkgConfig *optlib*: new parser
- I18nRubyGem *YAML based subparser*
- XRC *libxml*: new parser
Changes about parser specific kinds, roles, fields, and extras
- Asm
+ `section` kind is deleted.
- AutoIt
+ Drop `$` from tags for variables names.
- Automake
+ New extra `canonicalizedName`
+ New kind `pseudodir`
- C
+ New role `foreigndecl` for `function` kind
+ New role `foreigndecl` for `struct` kind
+ New field `section`
+ New field `alias`
- C++
+ New field `section`
+ New field `alias`
- CUDA
+ New field `section`
+ New field `alias`
- Fortran
+ New extra `linkName`.
- JavaScript
+ New role `foreigndecl` for `function` kind
- Kconfig
+ New kind `variable`
- LdScript
+ New role `destination` for `inputSection` kind
+ New role `aliased` for `symbol` kind
- Markdown
+ New kind `hashtag`
- SystemTap
+ New role `attached` for `probe` kind
- SystemVerilog
+ New kind `define`
Readtags
- Enhancement: add `-P, --with-psuedo-tags` option.
- Enhancement: add `-A, --absolute-input` and `-C, --canonicalize-input`
options.
See :ref:`readtags(1) `. for more details.
- Enhancement: add `-d, --debug` option for debugging purpose.
- Bugfix: make `--formatter` options works.
Merged pull requests
- Pull in the latest subtrees
- readtags: add --with-psuedo-tags option
- I18nRubyGem: add a new kind, "locale"
- Ruby: improve the way of parsing `Class.new(SuperClass)`
- XML Based Resource System (XRC): new parser
- I18nRubyGem: new parser
- docs(man): write about guest parsers
- Revise the release process
- PkgConfig: new parser
- rpmMacros: process areas surrounded by pairs of curly bracket
- Vera: revise the dataflow of cppGetc -> vStringPut
- nestlevel: Fix user data alignment
- Cxx: extract section information from __attribute__((section("SECTION")))
- NEWS: merge README.rst and README.md
- builds-sys/test: enhance check-genfile target
- various minor fixes
- GitHub Actions: disable BSD workflows again
- circleci: use fedora39
- misc/news.bash: generalize the script
- docs(web): manage versions of NEWS
- main: use the interval tree for filling scope field
- V for merging
- YACC: fix a typo in the pattern for skipping C strings
- Revise: the way of accessing the optVm's appData
- dsl: extend #/../ operator to be able to extract a matched group in the
pattern
- Docs: minor fixes
- misc/units.py: fix invalid escape sequences in regex patterns
- build-sys: don't use libxml-2 if its CRLF handling is broken
- SQL: extract views in "create view if not e
Re: [ITP] python-license-expression and cygport PoC patch
On 2024-06-06 13:28, Brian Inglis via Cygwin-apps wrote: On 2024-06-06 13:03, Brian Inglis via Cygwin-apps wrote: I found github/nexB/license-expression Python package to do SPDX licence checks developed by the same team doing SPDX-toolkit for SPDX, using the same current data, by and working with Fedora folks et al. Successful attempt to package Python license-expression (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210 https://cygwin.com/cgi-bin2/jobs.cgi?id=8210&srcpkg=playground&user=Brian+Inglis log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a 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 fully. 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! ;^> Also it is in PyPI and packaged by major Linux and BSD distros, and Msys2: https://repology.org/project/python:license-expression/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: [ITP] python-license-expression and cygport PoC patch
On 2024-06-06 13:03, Brian Inglis via Cygwin-apps wrote: I found github/nexB/license-expression Python package to do SPDX licence checks developed by the same team doing SPDX-toolkit for SPDX, using the same current data, by and working with Fedora folks et al. Successful attempt to package Python license-expression (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210 https://cygwin.com/cgi-bin2/jobs.cgi?id=8210&srcpkg=playground&user=Brian+Inglis log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a 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 fully. 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! ;^> -- 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
[ITP] python-license-expression and cygport PoC patch
I found github/nexB/license-expression Python package to do SPDX licence checks
developed by the same team doing SPDX-toolkit for SPDX, using the same current
data, by and working with Fedora folks et al.
Successful attempt to package Python license-expression (without tests):
https://cygwin.com/cgi-bin2/jobs.cgi?id=8210
log at:
https://github.com/cygwin/scallywag/actions/runs/9293093201
cygport attached and at:
https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a
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 fully.
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!
;^>
--
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
VERSION=30.3.0
RELEASE=1
BASE=${NAME#python-}
CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions)."
ARCH=noarch
LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"
DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"
#!/usr/bin/python
"""spdx-license-expression.py - validate SPDX licence expression
Usage: spdx-license-expression.py
Author: Brian Inglis
"""
from license_expression import get_spdx_licensing
import sys
def main(args):
if len(args) != 1:
print("usage: " + sys.argv[0] + " ",
file=sys.stderr)
return 1
licensing = get_spdx_licensing()
expression = args[0]
errs = licensing.validate(expression).errors
#ExpressionInfo(
# original_expression='... and MIT and GPL-2.0+',
# normalized_expression=None,
# errors=['Unknown license key(s): ...'],
# invalid_symbols=['...']
#)
for e in errs:
print(e, file=sys.stderr)
if len(errs) >= 1:
return 2
if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))
--- origsrc/lib/pkg_pkg.cygpart.orig2023-03-08 06:07:57.0 -0700
+++ src/lib/pkg_pkg.cygpart 2024-05-29 14:18:46.534998000 -0600
@@ -625,6 +641,7 @@ _EOF
fi
if [ -n "${LICENSE}" ]
then
+ spdx-license-expression.py "${LICENSE}" || true
cat >> ${distdir}/${PN}/${PN}-${PVR}-src.hint
<<-_EOF
license: ${LICENSE}
_EOF
$ for licp in $(grep -l '^LICENSE=.\+$' */*.cygport)
do
pkg=${licp%/*}
cp=${licp#*/}
cd $pkg/
eval $(cygport $cp vars LICENSE)
echo $pkg $cp "$LICENSE"
spdx-license-expression.py "$LICENSE" && \
echo SPDX licence validated: "$LICENSE"
cd -
done
a2ps a2ps.cygport GPL-3.0-or-later
SPDX licence validated: GPL-3.0-or-later
asr-manpages asr-manpages.cygport Authors
Unknown license key(s): Authors
bash-completion bash-completion.cygport GPL-2.0-or-later
SPDX licence validated: GPL-2.0-or-later
bash-completion bash-completion-spec.cygport GPL-2.0-or-later
SPDX licence validated: GPL-2.0-or-later
bind bind.cygport MPL-2.0 AND ISC AND MIT AND BSD-3-Clause AND BSD-2-Clause
SPDX licence validated: MPL-2.0 AND ISC AND MIT AND BSD-3-Clause AND
BSD-2-Clause
bison bison.cygport GPL-3.0-or-later
SPDX licence validated: GPL-3.0-or-later
ca-certificates ca-certificates.cygport Mozilla Public Licence 2.0
Unknown license key(s): Mozilla Public Licence 2.0
calm calm.cygport MIT
SPDX licence validated: MIT
c-ares c-ares.cygport MIT
SPDX licence validated: MIT
coreutils coreutils.cygport GPL-3.0-or-later AND GFDL-1.3-or-later
SPDX licence validated: GPL-3.0-or-later AND GFDL-1.3-or-later
cpuid cpuid.c
Re: [ITA] ctags
On 2024-06-06 12:31, Brian Inglis via Cygwin-apps wrote: On 2024-06-06 02:32, Brian Inglis via Cygwin-apps wrote: On 2024-06-05 12:48, Jon Turney via Cygwin-apps wrote: On 12/08/2016 20:41, Corinna Vinschen wrote: On Aug 12 11:57, Warren Young wrote: On Aug 12, 2016, at 7:57 AM, Corinna Vinschen Cool! If you want to take over ctags and test universal ctags for Cygwin, feel free if Warren agrees. I'm interested in doing ITA on ctags as gvim-X user to get onto u-ctags! Frank, It looks like we never got a universal-ctags package, so I'm not sure what the status of exuberant-ctags maintainer-ship is... Frank was a contributor to u-ctags ~2015 but seemed mainly for Windows and Notepad++ plug in development. I would like to adopt ctags and update it to successor universal-ctags. Successful package build with a couple of failed tests with known causes: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ctags log at: https://github.com/cygwin/scallywag/actions/runs/9399504588 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/ctags/tree/ctags.cygport?h=playground Packaged universal-ctags 6.1 performance was: Timetagspackage 6s 8MBctags source tree including multi-language test examples 12s 22MBnewlib-cygwin source tree -- 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] ctags
On 2024-06-06 02:32, Brian Inglis via Cygwin-apps wrote:
On 2024-06-05 12:48, Jon Turney via Cygwin-apps wrote:
On 12/08/2016 20:41, Corinna Vinschen wrote:
On Aug 12 11:57, Warren Young wrote:
On Aug 12, 2016, at 7:57 AM, Corinna Vinschen
Cool! If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees.
I'm interested in doing ITA on ctags as gvim-X user to get onto u-ctags!
Frank,
It looks like we never got a universal-ctags package, so I'm not sure what the
status of exuberant-ctags maintainer-ship is...
Frank was a contributor to u-ctags ~2015 but seemed mainly for Windows and
Notepad++ plug in development.
I would like to adopt ctags and update it to successor universal-ctags.
Successful package build with a couple of failed tests with known causes:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=ctags
log at:
https://github.com/cygwin/scallywag/actions/runs/9399504588
cygport attached and at:
https://cygwin.com/cgit/cygwin-packages/ctags/tree/ctags.cygport?h=playground
--
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
# ctags.cygport - ctags Cygwin package build control script definitions
# converted by rpmspec2cygport.sh 1.1 2024-06-06 07:47:49+
NAME=ctags
VERSION=6.1.0
RELEASE=1
CATEGORY="Text Devel"
SUMMARY="Programming language source indexing and cross-reference tool"
DESCRIPTION="Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of
language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming."
PROJECT=universal-$NAME
HOMEPAGE=https://github.com/$PROJECT/$NAME
HOMEPAGE=https://$NAME.io/
SRC_DIR=$PROJECT-$VERSION
SRC_URI=https://github.com/$PROJECT/$NAME/releases/download/v$VERSION/$PROJECT-$VERSION.tar.gz
DEBIAN=https://sources.debian.org/data/main/${NAME:0:1}/$NAME/$VERSION-$RELEASE/debian/patches
FEDORA=https://src.fedoraproject.org/rpms/$NAME/raw/master/f
OPENSUSE=https://raw.githubusercontent.com/bmwiedemann/openSUSE/master/packages/${NAME:0:1}/$NAME
PATCH_URI=
DEPEND="libiconv-devel libjansson-devel libpcre2-devel"
DEPEND+=" libxml2-devel libyaml-devel" # libseccomp-devel(Linux)
DEPEND+=" autoconf automake gcc-core make pkg-config python39-docutils"
BUILD_REQUIRES="$DEPEND"
unset DEPEND
CYGCONF_ARGS=--enable-etags
#--enable-coverage-gcov enable 'gcov' coverage testing tool [no]
#--enable-cross-guesses={conservative|risky}specify policy for
cross-compilation guesses
#--enable-custom-config=FILEenable custom config file for site-wide
defaults
#--enable-debugging enable debugging features
#--enable-dependency-tracking do not reject slow dependency extractors
# --disable-dependency-tracking speeds up one-time build
#--enable-etags enable the installation of links for
etags
# --disable-extended-format disable extension flags; use original
ctags file format only
# --disable-external-sort use internal sort algorithm instead of
sort program
# --disable-iconv disable multibyte character encoding
support
# --disable-json disable json support
# --disable-largefile omit support for large files
#--enable-macro-patternsuse patterns as default method to locate
# macros instead of line numbers
# --disable-option-checking ignore unrecognized --enable/--with
options
# --disable-pcre2 disable pcre2 support
# --disable-readcmd do not include readtags command during
install
# --disable-seccomp disable seccomp support
#--enable-silent-rules less verbose build output (undo:
Re: Up for adoption: ctags and expat
On 2024-06-05 12:48, Jon Turney via Cygwin-apps wrote: On 12/08/2016 20:41, Corinna Vinschen wrote: On Aug 12 11:57, Warren Young wrote: On Aug 12, 2016, at 7:57 AM, Corinna Vinschen Cool! If you want to take over ctags and test universal ctags for Cygwin, feel free if Warren agrees. I'm interested in doing ITA on ctags as gvim-X user to get onto u-ctags! Frank, It looks like we never got a universal-ctags package, so I'm not sure what the status of exuberant-ctags maintainer-ship is... Frank was a contributor to u-ctags ~2015 but seemed mainly for Windows and Notepad++ plug in development. -- 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: newer version of mingw64-*-win-iconv ?
On 2024-06-03 20:45, Bruno Haible wrote: Brian Inglis wrote: Packages are test builds for now. If Bruno reports no issues, can untest to stable. I report: No issues. I installed these two packages in my Cygwin 3.5.3 machine (from the mirrors.kernel.org mirror) and built a testdir of nearly all of Gnulib — which contains between 30 and 50 unit tests that are sensitive to the quality of the 'iconv' implementation —, and all these tests pass. Thanks Bruno, Just untest-ed these to promote to stable. Will announce when I see confirmation of the 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
Re: newer version of mingw64-*-win-iconv ?
On 2024-06-03 13:27, Jon Turney via Cygwin-apps wrote: On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote: On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote: On 29/05/2024 07:58, Brian Inglis via Cygwin wrote: [...] Could someone please do any further tweaks for this source git if required, and do NMU builds and deploys of these? I've given you NMU privileges, so now that someone can be you! Thanks Jon, I think and hope! ;^> I uploaded both arch packages and have not heard anything from calm about mingw64-i686-win-iconv but did get a non-maintainer complaint about: From: cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org To: Brian Inglis ... Reply-To: cygwin-apps-rdbxbdvo6bxqt0dzr+a...@public.gmane.org Subject: calm: cygwin package report for Brian Inglis X-Calm-Report: 1 Message-Id: <171738805632.3596610.16241297892116907567-vpjudf68pyp0lzk1ysf9sd64mghar...@public.gmane.org> Date: Mon, 03 Jun 2024 04:14:16 - X-Calm: 1 ... WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for maintainer 'Brian Inglis' WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for maintainer 'Brian Inglis' SUMMARY: 2 WARNING(s) and there is not yet any sign of either being applied to the master setup.ini at cygwin.com, which is my other confirmation that an announcement would be appropriate, without waiting for mirror updates. So is there anything more I have to or can do for these? Do I have to add some kind of NMU flag for the packages somehow? No, that's just me being distracted and forgetting to restart the thing so it re-reads the list. Thanks Jon, Need to teach `calm` about some self-HUP! ;^> Sorry about that. Hopefully working now. No worries. Got adding '!ready' manually to package dirs in lftp down pat. Packages are test builds for now. If Bruno reports no issues, can untest to stable. No previous debuginfo packages exist - are these not useful with cross builds? 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: newer version of mingw64-*-win-iconv ?
On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote: On 29/05/2024 07:58, Brian Inglis via Cygwin wrote: 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? I've given you NMU privileges, so now that someone can be you! Thanks Jon, I think and hope! ;^> I uploaded both arch packages and have not heard anything from calm about mingw64-i686-win-iconv but did get a non-maintainer complaint about: From: cygwin-no-re...@cygwin.com To: Brian Inglis ... Reply-To: cygwin-apps@cygwin.com Subject: calm: cygwin package report for Brian Inglis X-Calm-Report: 1 Message-Id: <171738805632.3596610.16241297892116907...@server2.sourceware.org> Date: Mon, 03 Jun 2024 04:14:16 - X-Calm: 1 ... WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for maintainer 'Brian Inglis' WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list for maintainer 'Brian Inglis' SUMMARY: 2 WARNING(s) and there is not yet any sign of either being applied to the master setup.ini at cygwin.com, which is my other confirmation that an announcement would be appropriate, without waiting for mirror updates. So is there anything more I have to or can do for these? Do I have to add some kind of NMU flag for the packages somehow? [Are we really still building 32 bit mingw packages when we dropped support of 32 bit Windows << 1%? There's a difference between "we don't support running on 32-bit Windows" and "We don't support cross-compiling to 32-bit Windows". Now, I'd like to do this in an evidence based manner e.g. if we had some statistics on packages that cygwin users choose to install, and hardly anyone was bothering with mingw 32-bit packages, then dropping them would be a good way of conserving our very limited maintainer resource. But as previously observed, that depends on building something to collect that data, which SHTDI. (There's also some unfinished work by Yaakov in a branch of the cygport repo which enhances cross-compile support, so that a single source package can produce mingw-cross install packages for multiple architectures, which would make it easier to continue to support these packages, and/or drop them in future, and/or add mingw arm64 cross-packages when the toolchain for them exists...) Should have made some arrangement with mirror ops for package download log stats to be generated and emailed to an Cygwin address for automatic processing. Could we just ask on the Cygwin list if any devs still build with them? I know from comments elsewhere that there are still systems and appliances out there in some regions where XP 32 bit is still in the majority: stats for << 1% 32 bit are global! What matters is whether Windows 32 bit libraries, programs, and systems, are being actively maintained or developed for using our tools and libraries, like all the other embedded targets we know Cygwin is being used as a development platform for with newlib, RTEMS, 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
[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
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?).
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...)
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.
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!
;^>
--
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
VERSION=30.3.0
RELEASE=1
BASE=${NAME#python-}
CATEGORY=Python
SUMMARY="Python license expression utility library"
DESCRIPTION="Python utility library to parse, compare, simplify and normalize
license expressions (such as SPDX license expressions)."
ARCH=noarch
LICENSE=Apache-2.0
LICENSE_SPDX="SPDX-License-Identifier: $LICENSE"
# SPDX-License-Identifier: Apache-2.0
LICENSE_URI="NOTICE apache-2.0.LICENSE"
DOCS="
license-expression.ABOUT
AUTHORS.rst CHANGELOG.rst CODE_OF_CONDUCT.rst README.rst
$LICENSE_URI
"
#!/usr/bin/python
"""spdx-license-expression.py - validate SPDX licence expression
Usage: spdx-license-expression.py
Author: Brian Inglis
"""
from license_expression import get_spdx_licensing
import sys
def main(args):
if len(args) != 1:
print("usage: " + sys.argv[0] + " ",
file=sys.stderr)
return 1
licensing = get_spdx_licensing()
expression = args[0]
errs = licensing.validate(expression).errors
#ExpressionInfo(
# original_expression='... and MIT and GPL-2.0+',
# normalized_expression=None,
# errors=['Unknown license key(s): ...'],
# invalid_sy
Fwd: newer version of mingw64-*-win-iconv ?
On 2024-05-29 02:53, Bruno Haible via Cygwin wrote: Brian Inglis wrote: 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 and https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-i686-win-iconv Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding? v0.0.8 is good enough. Hardly anyone needs UCS-2-INTERNAL. But many programs need a working ASCII encoding, which is fixed in v0.0.8. NMU updates of the above packages would be appreciated, based on those mingw...-win-iconv playground branch updates, if someone could help, please? -- 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
[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 defin
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&repository=dateutils&page=1&per_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&repository=dateutils&page=1&per_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
