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=playground=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=playground=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-are
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: "make
V=1")
# --disable
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: Request for support: some web pages on your site not responding
On 2024-06-03 21:14, Isabella Parker via Cygwin wrote:
I've encountered difficulties accessing specific resources on your website
cygwin.org as some pages fail to load. Would you mind providing me with the
contact details of the responsible person to resolve this issue?
Appreciate your assistance!
This mailing list is where available volunteers respond to help project users.
Please use cygwin.com in case of difficulties with cygwin.{org,net} - they were
registered to protect the name, and some issues may still occasionally occur at
the edge.
Please include precise details of your system and browser setup, and all issues
you encounter on cygwin.com.
Someone with relevant experience will respond to your issues, and if necessary,
ask the infrastructure team to deal with any problems.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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_symbols=['...']
#)
for e in errs:
print(e, file=sys.stderr)
i
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
Re: 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ITP] python-license-expression and cygport PoC patch (was: calm: SPDX licence list data update please)
On 2024-05-28 08:37, Brian Inglis via Cygwin-apps wrote: On 2024-05-27 15:15, Jon Turney via Cygwin-apps wrote: On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote: Can we please get the SPDX licence list data updated in calm to 3.24 sometime if possible as the licences complained about below have been in I thought I wrote about this the last time you asked, but obviously not. Thought not, but after recent reminder, not so sure now ;^> This is not quite straightforward, as the system python on sourceware is currently python3.6, and the last supported nexB/license-expression on that is 30.0.0, and moving to a later one has some wrinkles, since various pieces of interconnected stuff aren't venv'd (yet?). releases for nearly a year since 3.21: If not, perhaps I could be of some help if I knew requirements? So, there aren't any requirements here except "validate the SPDX license expression to detect maintainer mistakes and typos". It looks like using that python module might have been a mistake. I'm not sure why it needs to contain it's own version of the license data, ideally we'd have something that read the official SPDX data (ratelimited to once per day or something. It looks like maybe this would possible to do by feeding our own license list into the module rather than using it's built in one, but one could hope for this to be built in already...) There have been changes in how to specify exceptions using WITH. It would also be useful if it could also be taught to accept 'LicenseRef-.*' identifiers. Ditto ExceptionRef-.* but that and LicenseRef-.* do not seem to be allowed by PEP 639, as they unrealistically expect projects to change existing licences, whereas we have to deal with historical reality like Fedora! So, suggestions on a different module to use, or patches to make this work better, or cogent arguments why we should just remove this validation are all welcome. How about if we delegate licence validation to cygport, as someone recently offered, or as currently done in calm, with current Cygwin python - add licence validation hint to src hint - if not there, calm does it as now? Would we or should we also allow specifying LICENSE_URI (as I have been doing) like PEP 639 license-files, with defaults searched as suggested: "LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"? where globs and source paths are allowed as usual in cygport files, and directories may match these paths, implicitly including file entries, but no file *contents* checked, unless we see a need in future, to generate and validate licences. You can also now remove the exceptions in calm/fixes.py(licmap): Thanks, will do so. Cheers! I found github/nexB/license-expression Python package to do SPDX licence checks with current data, developed by the same team doing SPDX-toolkit for SPDX, working with Fedora folks et al. Successful attempt to package Python license-expression (without tests): https://cygwin.com/cgi-bin2/jobs.cgi?id=8210 cygport attached and at: https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a log at: https://github.com/cygwin/scallywag/actions/runs/9293093201 The package installs and runs using PoC attached in spdx-license-expression.py script hooked into /usr/share/cygport/lib/pkg_pkg.cygpart license hint addition patch attached. I also ran a test of the Python script and module against all package source cygport files declaring licences which I maintain or ever looked at, including a git/cygwin-packages/*.cygport download from 2023-02, showing the results in the attached log. I also attempted to trap the exceptions in the script, but that does not seem to work in any documented obvious manner, but I do not know enough Python to address this. If someone else who knows python cared to adopt and improve this in a more normal manner, and incorporate this more smoothly into cygport, we could all appreciate that. Alternatively, some candid comments and frank feedback might allow me to do so! ;^> The approach may also be adaptable to calm if you can get python-license-expression 30.3.0 installed on the server(s), and kept updated: https://repology.org/project/python:license-expression/versions and Cygwin should soon be added there hopefully! ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry#|/usr/bin/cygport # python-license-expression.cygport - Python license-expression Cygwin package build control script definitions inherit python-wheel NAME=python-license-expression VERS
Re: newer version of mingw64-*-win-iconv ?
On 2024-05-28 19:12, Bruno Haible via Cygwin wrote: It would be useful if someone could rebuild the two packages https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html based off the current git HEAD [1]. Reason: The current git HEAD is a reasonable alternative to GNU libiconv; all encodings that it supports, other than EUC-JP and GB18030, have reasonably good conversion tables. Wherease the current Cygwin packages are based off source code from 2013 and have a major problem already with the ASCII encoding. [1] https://github.com/win-iconv/win-iconv Ran playground local and CI builds of these packages at v0.0.8 successfully: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding? Could someone please do any further tweaks for this source git if required, and do NMU builds and deploys of these? [Are we really still building 32 bit mingw packages when we dropped support of 32 bit Windows << 1%? Steam estimated 32 bit games PCs ~ 0.25% in 2021, and dropped support in February. Surveys don't even bother to report that share nowadays!] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: new git update fails with fatal: fetch-pack: invalid index-pack output
On 2024-05-27 16:10, Dan Shelton via Cygwin wrote: I can replicate the 'fatal: fetch-pack: invalid index-pack output' error with https://github.com/gcc-mirror/gcc.git, but only every 11-20 attempts. I think this is a race condition somewhere, maybe in the threading code? SO suggestions are other git versions in the path, bad downstream proxy cache, slow or invasive network security appliance, which may be bypassed with ssh or VPN URIs, low resource limits in containers, which can be relieved by bumping resources or reducing sizes: git config pack.windowMemory 10m git config pack.packSizeLimit 20m or huge repos which can be alleviated by a shallow clone --depth=1. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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: new git update fails with fatal: fetch-pack: invalid index-pack output
On 2024-05-26 16:44, David Dyck via Cygwin wrote: After updating I still get the same error. $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4282 bytes) remote: Enumerating objects: 33941, done. remote: Counting objects: 100% (3786/3786), done. remote: Compressing objects: 100% (1328/1328), done. remote: Total 33941 (delta 2360), reused 3474 (delta 2243), pack-reused 30155 Receiving objects: 100% (33941/33941), 20.20 MiB | 17.42 MiB/s, done. fatal: fetch-pack: invalid index-pack output $ cygcheck -srv >cygcheck.out cygcheck: dump_sysinfo: GetVolumeInformation() for drive S: failed: 53 $ git --version git version 2.45.1 $ cygcheck -c git Cygwin Package Information Package VersionStatus git 2.45.1-1 OK $ type git git is hashed (/usr/bin/git) attached cygcheck.out Retry running git prefixed with PATH=/usr/bin:/bin/:/usr/sbin:/sbin ISTR in the past having to lose MS dirs from my Cygwin PATH. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: new git update fails with fatal: fetch-pack: invalid index-pack output
On 2024-05-26 06:03, Adam Dinwoodie via Cygwin wrote: On Sun, 26 May 2024 at 05:10, David Dyck via Cygwin wrote: I upgraded to the most recent git and I get the following error ( stable2.45.1-1x86_648597 KiB2024-05-25 18:58 ) $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4281 bytes) remote: Enumerating objects: 33933, done. remote: Counting objects: 100% (3778/3778), done. remote: Compressing objects: 100% (1322/1322), done. remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused 30155 Receiving objects: 100% (33933/33933), 20.19 MiB | 15.38 MiB/s, done. fatal: fetch-pack: invalid index-pack output when I downgraded to 2.43.0-1x86_648402 KiB2024-01-07 20:32 I was able to get the repository download $ git clone -v https://github.com/lxml/lxml.git Cloning into 'lxml'... POST git-upload-pack (175 bytes) POST git-upload-pack (gzip 8652 to 4281 bytes) remote: Enumerating objects: 33933, done. remote: Counting objects: 100% (3778/3778), done. remote: Compressing objects: 100% (1322/1322), done. remote: Total 33933 (delta 2356), reused 3471 (delta 2241), pack-reused 30155 Receiving objects: 100% (33933/33933), 20.19 MiB | 13.13 MiB/s, done. Resolving deltas: 100% (16518/16518), done. Thanks for the report. This is working fine for me locally. Can you please upgrade, check the problem is still recurring, and provide the output from `cygcheck -srv >cygcheck.out`? I got the same symptom yesterday from the previous git version on the recently updated curl repo, and just put it down to traffic, as `git pull --ff` worked immediately after, as did a later `git remote update`: $ git remote update remote: Enumerating objects: 6617, done. remote: Counting objects: 100% (4385/4385), done. remote: Compressing objects: 100% (280/280), done. error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8) error: 4751 bytes of body are still expected fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output $ git --version git version 2.43.0 Of course, it could also be some issue with my latest curl build! ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: calm: SPDX licence list data update please
Hi folks,
Can we please get the SPDX licence list data updated in calm to 3.24 sometime if
possible as the licences complained about below have been in releases for nearly
a year since 3.21:
On 2024-05-24 02:18, cygwin-no-re...@cygwin.com wrote:
INFO: package 'man-pages-linux': errors in license expression: ['Unknown
license key(s): Linux-man-pages-1-para, Linux-man-pages-copyleft-var,
Linux-man-pages-copyleft-2-para']
https://github.com/spdx/license-list-XML/releases/tag/v3.21
https://github.com/spdx/license-list-data/releases
https://github.com/spdx/license-list-data/tree/main/json
https://github.com/spdx/license-list-data/tree/main/jsonld
https://spdx.github.io/license-list-data/
If these are handled by PEP-0639/pip/NexB/SPDX license-expression, possibly
someone could package it and license-list-data and add to calm prereqs?
If not, perhaps I could be of some help if I knew requirements?
You can also now remove the exceptions in calm/fixes.py(licmap):
https://cygwin.com/git/?p=cygwin-apps/calm.git;a=blob;f=calm/fixes.py;h=1f67d131d49d68c93f96548af1947dd405b4f743;hb=HEAD#l150
for my packages dash, cpuid, units, grep, gzip, readline, unifont, bison, wget,
libgcrypt, mingw64-*-/libidn, mingw64-*-/libidn2, mingw64-*-/curl,
man-pages-{linux,posix}, vttest, tz{code,data}:
BSD-3-Clause AND GPL-2.0-or-later
dash/dash.cygport:LICENSE="BSD-3-Clause AND GPL-2.0-or-later"
GPL-2.0-or-later
cpuid/cpuid.cygport:LICENSE=GPL-2.0-or-later
GPL-3.0-or-later
units/units.cygport:LICENSE="GPL-3.0-only AND GFDL-1.3-only"
GPL-2.0-or-later
grep/grep.cygport:LICENSE=GPL-2.0-or-later
gzip/gzip.cygport:LICENSE=GPL-2.0-or-later
readline/readline.cygport:LICENSE=GPL-3.0-or-later
GPL-2.0-or-later WITH Font-exception-2.0 OR OFL-1.1,
unifont/unifont.cygport:LICENSE="(GPL-2.0-with-font-exception OR OFL-1.1) AND
GPL-2.0-or-later AND LicenseRef-Unifoundry-Unifont-Public-Domain"
**I will update Unifont as I see GPL...-exception is now deprecated**
and 16 is in beta preview.
Can we just split these long quoted strings or do we need \ line continuations?
And does anyone know if there is a convention for splitting licence expressions
in comments across lines?
GPL-3.0-or-later
bison/bison.cygport:LICENSE=GPL-3.0-or-later
wget/wget.cygport:LICENSE=GPL-3.0-or-later
LGPL-2.1-or-later AND GPL-2.0-or-later
libgcrypt/libgcrypt.cygport:LICENSE="LGPL-2.1-or-later AND GPL-2.0-or-later AND
(GPL-2.0-only OR BSD-3-Clause) AND BSD-3-Clause"
(LGPL-3.0-or-later OR GPL-2.0-or-later) AND GPL-3.0-or-later,
libidn/libidn.cygport:LICENSE="LGPL-3.0-or-later AND GPL-2.0-or-later AND
GPL-3.0-or-later AND GFDL-1.3-or-later"
libidn/mingw64-i686-libidn/mingw64-i686-libidn.cygport:LICENSE=LGPLv3+/GPLv2+/GPLv3+/GFDLv1.3+
libidn/mingw64-x86_64-libidn/mingw64-x86_64-libidn.cygport:LICENSE="LGPL-3.0-or-later
AND GPL-2.0-or-later AND GPL-3.0-or-later AND GFDL-1.3-or-later"
(LGPL-3.0-or-later OR GPL-2.0-or-later) AND GPL-3.0-or-later AND
Unicode-DFS-2016,
libidn2/libidn2.cygport:LICENSE="LGPL-3.0-or-later AND GPL-2.0-or-later AND
GPL-3.0-or-later AND Unicode-TOU AND Unicode-DFS-2016"
libidn2/mingw64-i686-libidn2/mingw64-i686-libidn2.cygport:LICENSE="LGPL-3.0-or-later
AND GPL-2.0-or-later AND GPL-3.0-or-later AND Unicode-TOU AND Unicode-DFS-2016"
libidn2/mingw64-x86_64-libidn2/mingw64-x86_64-libidn2.cygport:LICENSE="LGPL-3.0-or-later
AND GPL-2.0-or-later AND GPL-3.0-or-later AND Unicode-TOU AND Unicode-DFS-2016"
curl
curl/curl.cygport:LICENSE=curl
curl/mingw64-i686-curl/mingw64-i686-curl.cygport:LICENSE=curl
curl/mingw64-x86_64-curl/mingw64-x86_64-curl.cygport:LICENSE=curl
Linux-man-pages-copyleft
man-pages-linux/man-pages-linux.cygport:LICENSE="MIT \
man-pages-posix/man-pages-posix.cygport:LICENSE=Linux-man-pages-copyleft
BSD-Source-Code
vttest/vttest.cygport:LICENSE=BSD-Source-Code
BSD-3-Clause AND Public-Domain
tzdata/tzdata.cygport:LICENSE=LicenceRef-IANA-TZ-Public-Domain
tzcode/tzcode.cygport:LICENSE=LicenceRef-IANA-TZ-Public-Domain
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: [ITA] dateutils
On 2024-05-21 09:57, Brian Inglis via Cygwin-apps wrote:
On 2024-05-21 07:17, Jon Turney via Cygwin-apps wrote:
On 17/05/2024 06:43, Brian Inglis via Cygwin-apps wrote:
Date manipulation utilities
I would like to adopt the above orphaned package.
Thanks.
I added this to your packages.
https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground
Please cleanup all the commented out detritus.
Sure!
What is the reasoning for changing SRC_URI to point to github? The project
homepage still points to bitbucket.org for downloads.
They provide the same release tarball on github, and README on both sites state
that "Dateutils are hosted primarily on github:", so I see no reason to use what
appears to be the legacy repo at another site, although I would treat them as
project mirrors if possible.
Looking at latest release downloads they are 50/50 across both sites so far,
although the signature downloads from github are much higher; see:
https://bitbucket.org/hroptatyr/dateutils/downloads/
https://somsubhra.github.io/github-release-stats/?username=hroptatyr=dateutils=1_page=100
"*** Warning: DEPEND is deprecated, use BUILD_REQUIRES instead."
Scallywag runs:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils
The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?
Can you share the reasoning that lets your reach that conclusion from:
FAIL: tzmap_check_02.ctst
The original failure log messages from xargs complained about lack of
environment space.
The build directory should be available as an artifact which may contain more
detailed information on the failure.
I wish - the test runner is very tidy - just the trs and log.
Have you established that this failure is not a regression?
Running standalone from test dir with:
$ make --trace TESTS=tzmap_check_02.ctst V=1 check
passes with all the usual messages - attached.
Error message in attached log is:
xargs: environment is too large for exec
consistent across local and scallywag builds.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry$ find "${root}/lib" "${TZMAP_DIR}/../lib" -name '*.tzmcc' | xargs "${TZMAP}"
check
xargs: environment is too large for exec
$? 1
FAIL tzmap_check_02.ctst (exit status: 1)
Re: libtool can't build shared library unless -no-undefined specified
On 2024-05-21 07:18, Jon Turney via Cygwin-apps wrote: On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote: On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote: On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote: Trying to update dateutils, autotools build fails with: libtool: error: can't build x86_64-pc-cygwin shared library unless -no-undefined is specified Suggestions for overrides or fixes? Tried: LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined" CYGCONF_ARGS=" --enable-contrib --enable-tzmap-fetch lt_no_undefined_flag=--no-undefined no_undefined_flag=--no-undefined You and I discussed this a few years ago in connection with curl. The solution there, and in most similar cases, is to add -no-undefined to the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am. See Had to patch into lib AM_LDFLAGS variable, then found out that library was not for use in open source packages, but only required to link with a (missing) proprietary MatLab module, so dropped the config --enable-contrib option! Yeah, building stuff for Cygwin often requires adding this flag in the appropriate places, to say "yes, I really do want a shared library". https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode -no-undefined Declare that output-file does not depend on any libraries other than the ones listed on the command line, i.e., after linking, it will not have unresolved symbols. Some platforms require all symbols in shared libraries to be resolved at library creation (see Inter-library dependencies), and using this parameter allows libtool to assume that this will not happen. Note that because this flag doesn't do anything for non-PE targets, it's (a) always safe to upstream, and (b) doesn't actually prevent development from unwittingly introducing unresolved symbols. In that case, could we ask Bruno to add into gnulib somewhere appropriate? This should probably be mentioned in the FAQ item on PE linkage peculiarities. In libtool info? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [ITA] bash-completion/-devel
On 2024-05-21 07:19, Jon Turney via Cygwin-apps wrote: On 03/05/2024 14:40, Jon Turney via Cygwin-apps wrote: On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote: I would like to co-maintain or adopt and revive the above package, which was adopted by Eric but not updated since Yaakov. Thanks. I added this to your packages. I guess I need to ask eblake if he wants to orphan his packages, since he seems to be no longer active... Excluding co-maintained packages, the list is: $ grep 'Eric Blake' cygwin-pkg-maint | grep -v '/' bashdb Eric Blake cppi Eric Blake cvsps ORPHANED (Eric Blake) cvsutils Eric Blake gperf Eric Blake libsigsegv Eric Blake sharutils Eric Blake I looked at cvsutils and sharutils and concluded that they were unlikely to be upgraded upstream, although you can add my name to those if you wish. I do not remember looking at the others, although some may be in a similar state, or gone walkabout, and I did not have sufficient interest to recall. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [ITA] dateutils
On 2024-05-21 07:17, Jon Turney via Cygwin-apps wrote:
On 17/05/2024 06:43, Brian Inglis via Cygwin-apps wrote:
Date manipulation utilities
I would like to adopt the above orphaned package.
Thanks.
I added this to your packages.
https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground
Please cleanup all the commented out detritus.
Sure!
What is the reasoning for changing SRC_URI to point to github? The project
homepage still points to bitbucket.org for downloads.
They provide the same release tarball on github, and README on both sites state
that "Dateutils are hosted primarily on github:", so I see no reason to use what
appears to be the legacy repo at another site, although I would treat them as
project mirrors if possible.
Looking at latest release downloads they are 50/50 across both sites so far,
although the signature downloads from github are much higher; see:
https://bitbucket.org/hroptatyr/dateutils/downloads/
https://somsubhra.github.io/github-release-stats/?username=hroptatyr=dateutils=1_page=100
"*** Warning: DEPEND is deprecated, use BUILD_REQUIRES instead."
Scallywag runs:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils
The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?
Can you share the reasoning that lets your reach that conclusion from:
FAIL: tzmap_check_02.ctst
The original failure log messages from xargs complained about lack of
environment space.
The build directory should be available as an artifact which may contain more
detailed information on the failure.
I wish - the test runner is very tidy - just the trs and log.
Have you established that this failure is not a regression?
Running standalone from test dir with:
$ make --trace TESTS=tzmap_check_02.ctst V=1 check
passes with all the usual messages - attached.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry$ find "${root}/lib" "${TZMAP_DIR}/../lib" -name '*.tzmcc' | xargs "${TZMAP}"
check
$? 0
PASS tzmap_check_02.ctst (exit status: 0)
:test-result: PASS
:global-test-result: PASS
:recheck: no
:copy-in-global-log: no
===
dateutils 0.4.11: test/test-suite.log
===
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?
On 2024-05-19 09:38, Jon Turney via Cygwin wrote: On 19/05/2024 00:17, Mark Geisert via Cygwin wrote: FWIW Although this wording seems to indicate Cygwin is still supported on 32-bit Windows, just discouraged. This seems like a willfully context-blind reading. The table above lists Windows versions for which support has been discontinued, which includes "All 32-bit". Further, https://cygwin.com/ plainly states "The Cygwin DLL currently works with all recent, commercially released x86_64 versions of Windows ...", which seems pretty unambiguous. Suggestions on how to improve this obviously welcomed. (but I'm not a big fan of "put fact A in place X as well as place Y, so people who ignored it in place Y because it didn't fit there priors can continue to ignore it in place X as well.") Best practice for any communication is: Tell them what you are going to tell them, Tell them what you want them to know, Tell them what you told them. -- Aristotelian Triptych That is presumably triply true for unwelcome news! "The human brain evidently operates on some variation of the famous principle enunciated in 'The Hunting of the Snark': 'What I tell you three times is true.'" -- Norbert Weiner, "Cybernetics" -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?
On 2024-05-18 14:13, Cedric Blancher via Cygwin wrote: On Sat, 18 May 2024 at 13:22, Roland Mainz via Cygwin wrote: On Fri, May 17, 2024 at 9:48 AM Cedric Blancher via Cygwin wrote: Is there a technical reason why 32bit Cygwin cannot be installed on 64bit Windows? We like to create a CI build pipeline, and want to create binaries for 32bit and 64bit Cygwin on the same machine, but setup.exe for 32bir Cygwin refuses to install Maybe the Cygwin 32bit setup wants to make sure only people who read the instructions can use it ? :-) This should work from an Admin cmd.exe console. snip # Install Cygwin 32bit on Windows 10 32bit with packages required by "ms-nfs41-client" (Windows NFSv4.1 client) # get installer from https://www.cygwin.com/setup-x86.exe setup-x86.exe --allow-unsupported-windows -q --no-verify --site http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 cygwin,cygwin-devel,cygrunsrv,cygutils,cygutils-extra,bash,bzip2,coreutils,getent,gdb,grep,hostname,less,libiconv,libiconv2,pax,pbzip2,procps-ng,sed,tar,time,util-linux,wget,libnfs,make,git,dos2unix snip That does only install the default packages for me, but not wget or cygrunserv. Is there a setup-x86.exe option just to add packages to an existing installation? Missing option -P/--packages before package list, which may be comma or (within quotes) space delimited. Installing cygport is equivalent of build essential on other distros. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?
On 2024-05-17 01:48, Cedric Blancher via Cygwin wrote: Is there a technical reason why 32bit Cygwin cannot be installed on 64bit Windows? We like to create a CI build pipeline, and want to create binaries for 32bit and 64bit Cygwin on the same machine, but setup.exe for 32bir Cygwin refuses to install Practical reason is 32 bit usage < 1% and Cygwin is all volunteer, with professionally and/or personally busy developers lacking time to do more. You are on your own with 32 bit dropped, so ask questions on forums like 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[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: cygwin application hangs on closing console
112
#3 0x7ffe4a145e08 in _cygtls::call2 (this=0x2aece00, func=0x7ffe4a1451ea
, arg=0x7ffe4a3355b8 ,
buf=buf@entry=0x2aecd50) at
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#4 0x7ffe4a145e86 in _cygtls::call (func=, arg=out>) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#5 0x7ffe84d4 in KERNEL32!BaseThreadInitThunk () from
C:\src\dlls-syms\kernel32.dll\640993B0ad000\kernel32.dll
#6 0x7ffe57981791 in ntdll!RtlUserThreadStart () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#7 0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 0x131c)]
#0 0x7ffe579d95f4 in ntdll!ZwWaitForWorkViaWorkerFactory () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0 0x7ffe579d95f4 in ntdll!ZwWaitForWorkViaWorkerFactory () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1 0x7ffe5794eb5e in ntdll!RtlReleaseSRWLockExclusive () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#2 0x7ffe4a145e08 in _cygtls::call2 (this=0x323ce00, func=0x7ffe5794e3f0
, arg=0xc0b60, buf=buf@entry=0x323cd50)
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#3 0x7ffe4a145e86 in _cygtls::call (func=, arg=out>) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#4 0x7ffe84d4 in KERNEL32!BaseThreadInitThunk () from
C:\src\dlls-syms\kernel32.dll\640993B0ad000\kernel32.dll
#5 0x7ffe57981791 in ntdll!RtlUserThreadStart () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#6 0x in ?? ()
(gdb) thread 5
[Switching to thread 5 (Thread 0x9b8)]
#0 0x7ffe579d95f4 in ntdll!ZwWaitForWorkViaWorkerFactory () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0 0x7ffe579d95f4 in ntdll!ZwWaitForWorkViaWorkerFactory () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1 0x7ffe5794eb5e in ntdll!RtlReleaseSRWLockExclusive () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#2 0x7ffe4a145e08 in _cygtls::call2 (this=0x343ce00, func=0x7ffe5794e3f0
, arg=0xc0b60, buf=buf@entry=0x343cd50)
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#3 0x7ffe4a145e86 in _cygtls::call (func=, arg=out>) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#4 0x7ffe84d4 in KERNEL32!BaseThreadInitThunk () from
C:\src\dlls-syms\kernel32.dll\640993B0ad000\kernel32.dll
#5 0x7ffe57981791 in ntdll!RtlUserThreadStart () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#6 0x in ?? ()
(gdb) thread 6
Unknown thread 6.
(gdb) thread 1
[Switching to thread 1 (Thread 0x11cc)]
#0 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) up
#1 0x7ffe54156d1f in WaitForSingleObjectEx () from
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
(gdb)
#2 0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914
1914 in /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc
(gdb) p thread_sync_event
$6 = (HANDLE) 0x1510
(gdb) p name
$7 = "cygcons.thread_sync.0", '\000' , "r", '\000' 183 times>...
(gdb) p con.owner
No symbol "con" in current context.
(gdb) p master_thread_started
$8 = true
(gdb) p unit
$9 = 0
(gdb) p shared_console_info
$10 = {0x1a003, 0x0 }
(gdb)
Sometimes a Cygwin strace can be helpful, for example:
$ strace -o drbdadm.strace drbdadm
or equivalent however you execute the program.
Attach the strace output as text if possible, otherwise if too big, xz, bz2, lz,
zstd, gz.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...
On 2024-05-13 07:34, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: *FileNormalizedNameInformation* 44/0x2e is defined in winternl.h FILE_INFORMATION_CLASS for NtQueryInformationFile: I see it's defined as 48/0x30 there, though... Good catch and point! My computer glasses did not seem to be working well last weekend! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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: Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...
On 2024-05-11 05:30, Roland Mainz via Cygwin wrote: I'm writing a test program for |FileNormalizedNameInfo| right now (see https://rovema.kpaste.net/07074abc). Per https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ne-minwinbase-file_info_by_handle_class |FileNormalizedNameInfo| should be |24|, but on Cygwin 3.6 I get the value |48|. Since |GetFileInformationByHandleEx()| gives me error 87 (="Invalid Parameter") for |48|, but works as intended for |24| I assume that the Cygwin header is wrong. Could someone please check the Cygwin header files ? Could someone please read the enum constant names and classes carefully? Package w32api-headers: Headers: snip $ grep -r FileNormalizedNameInfo /usr/include/ /usr/include/w32api/ddk/wdm.h: FileNormalizedNameInformation, /usr/include/w32api/minwinbase.h:*FileNormalizedNameInfo*, /usr/include/w32api/winternl.h:FileNormalizedNameInformation = 48, snip *FileNormalizedNameInfo* 24/0x18 is defined in minwinbase.h FILE_INFO_BY_HANDLE_CLASS for GetFileInformationByHandleEx whereas *FileNormalizedNameInformation* 44/0x2e is defined in winternl.h FILE_INFORMATION_CLASS for NtQueryInformationFile: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile ditto in ddk/wdm.h! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: calm: vaulting ancient unifont
On 2024-05-06 09:27, Jon Turney via Cygwin-apps wrote: On 04/05/2024 20:21, Brian Inglis via Cygwin-apps wrote: Thanks Jon? - yay! Right, I deployed some changes to calm which will gradually let us get rid of the "old-style" of obsoletion (where, as here, the old name of a package (i.e. font-unifont-misc, font-unifont-ttf) continues to exist with a category of _obsolete and requires: its replacement) (cygport stopped generating these some time ago (0.34.1, 2022), but they've been lingering around indefinitely, because in some cases it's only the existence of these packages which currently records the fact of the obsoletion) Since someone's bound to get the wrong end of the stick: This doesn't mean package maintainers should change anything. And just to reiterate: As a principle, every version of a package must contain complete instructions for upgrading to it. So, it is almost never correct to go "I'll remove these OBSOLETE instruction after one package release with them, since they've already happened everywhere..." On 2024-05-04 09:48, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote: INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz INFO: vaulting x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz INFO: vaulting x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz INFO: vaulting x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz SUMMARY: 8 INFO(s) Anyhow, double checking that the "right thing" happened here, I notice that 'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, especially since it contains the expected .dbg files etc. Brian, Are you sure that's right? It appears not! My reasoning was that as unifont-viewer was split out from unifont-fonts, unifont-viewer-debuginfo would be generated, but it appears that is not how that works. Is there any way to make that work, or should I just drop it in the next release, or a new -RELEASE? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages
On 2024-05-06 09:52, Jon Turney via Cygwin-apps wrote: On 01/05/2024 17:48, Brian Inglis via Cygwin-apps wrote: On 2024-04-30 23:32, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: Some package upstreams offer only checksums, for example .sha512sum, .sha256sum, for verification rather than gpg signatures, for example .asc, .sig, .sign, etc; use these checksum files when provided in a similar manner to gpg signatures; these files are often provided with fixed names which may be renamed on download to unique values using cygport URI fragment support like #/$NAME-VERSION.sha...sum; use coreutils cksum as it supports all modern and legacy checksums and formats. https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d Two similar independent implementations mean it would be a good idea to add the feature! Mine preferred cksum as being the most general approach, while not worrying or knowing too much about ancient sums, although your implementation is better, that is, works properly on those. Mine also preferred sha*sum file types, while still allowing prefixes only without sum, not enumerating them all in the unpack() case, and respecting the cksum crc default. I guess this makes sense as a part of the fetch operation, in those cases where upstream provides signatures or checksums. I will retry incorporating Achim's approach so hopefully we can both retire our local cygport patches. I would also appreciate other comments or feedback to my reply to Achim's NAK on my patch for `gpgv` replacing `gnupg2 --verify`? But as briefly discussed in [1], independently of that it would also be a good idea for cygport to specify it's own checksum file, which is incorporated into the source package, and verified at build prep time. As in Fedora RPM package `sources` BSD-style sum prefix, for example (one line): https://src.fedoraproject.org/rpms/bash-completion/blob/rawhide/f/sources SHA512 (bash-completion-2.13.0.tar.xz) = 7c65fea599a25c2c9d6ef300a9cc2d5fbabd0bcc9e09fe32bb706d3398936f40501171f03280f042465bc0d9aca4b1b53c2c13a99bbdfb6fe916767a267158af or also in the source package for cygport and each source file included, as in Debian dsc, for example: https://deb.debian.org/debian/pool/main/b/bash-completion/bash-completion_2.13.0-1.dsc Checksums-Sha1: 0c045cc06b57bbe8945bc6c4ea8f2b52f1285903 484155 bash-completion_2.13.0.orig.tar.gz 66f10d161e71c0725a61d5bde1c6b89f9bdb61e3 17840 bash-completion_2.13.0-1.debian.tar.xz Checksums-Sha256: 6c1cc04bb506e7ba6bd7bb3c7c6f6ad2b46e6198e8ef4c88139597250601 484155 bash-completion_2.13.0.orig.tar.gz d2de6c33d14843da64e4b20e6330c14079b2c73f04c9b4c544d6435930003a67 17840 bash-completion_2.13.0-1.debian.tar.xz Files: 93527b12850a781744e3f335f904bdf1 484155 bash-completion_2.13.0.orig.tar.gz a831ae35940daf95016fce1b655955a1 17840 bash-completion_2.13.0-1.debian.tar.xz (Since this would protect against such screw ups, help with build reproducibility, and defend against supply chain attacks on upstream) [1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html Coreutils `cksum` does BSD-style checksums, although I would prefer sha256 sums for brevity and consistency with setup.ini, and base64 encoding rather than hex to shorten the checksum representation, in recent coreutils. We all have SSH keys, which I also have as a GPG key, could we also use them for signing source packages? Calm could validate ours and checksums, and re-sign with Cygwin key, which setup could validate. Could osslsigncode have any application here? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
RFC: postinstall fontconfig cache changes
Hi folks,
Since Yaakov added the fontconfig cache postinstall script, it has been
selecting only fonts created by 'Microsoft Corp' and (recently?) matching
'*.ttf' (lower case only) for whatever reasons?
I have been running my own attached local fontconfig cache postinstall script,
with some tweaks, such as putting my symlinks into font directory 'windows'
instead of fontconfig package's 'microsoft', using `cygpath -UW` so the symlinks
to Windows/Fonts created survive changes I made to cygdrive over the years,
adding .ttf fonts not created by 'Microsoft Corp' including those only
'Microsoft supplied', original Windows .TTF (uppercase) fonts installed with the
system, .ttc font collections which are supported by recent fontconfig, and .otf
OpenType fonts provided with newer font packages, as Pango and Harfbuzz do not
appear to support some recent TrueType hinting changes.
I also have to clean up the cache directory, as it sometimes got to *many* 1000s
of cache files, taking up GB, a known but unsolved? (may now be fixed) issue
with "broken" [see NEWS] font cache handling, whereas after resetting it has
only dozens of cache files taking a dozen MB, created in ~10s for ~3600 fonts,
from Windows, packages, and local downloads and installs.
I would like to request consideration for adding all Windows fonts of supported
types of any case to the cache every startup.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry#!/bin/dash
# zp_l_fontconfig_cache.dash - update Windows non-MS Corp ttf, TTF, ttc, and
otf font links and rebuild font cache
winfontsdir=/usr/share/fonts/windows
cache=/var/cache/fontconfig
mscorp='Microsoft Corp'
win="$(cygpath -UW)/Fonts" # ln to /proc/cygdrive in case mount changes
later
/bin/mkdir -p $winfontsdir
# remove any broken links (-L -type l together)
/usr/bin/find -L $winfontsdir -type l -delete
# find Windows .TTF, .otf, .ttc and non-MS Corp .ttf fonts and link between
fonts dirs
# Notes:
# system
# DUBAI-*, MTEXTRA, others are 'Microsoft supplied font';
# all *.TTF are 'Microsoft Corp'; some are also 'Microsoft supplied font';
# .../Fonts may have Deleted subdirectory;
# grep -L returns names of files with no pattern matches;
# fontconfig handles ttc TrueType collections and otf OpenType fonts
/usr/bin/find "$win" -maxdepth 1 -type f\
\( -name '*.ttf' -exec /bin/grep -FaL "$mscorp" '{}' + \) \
-o \( -name '*.TTF' -print \) \
-o \( -iname '*.ttc' -print \) \
-o \( -iname '*.otf' -print \) | \
while read f
do
[ -e "$winfontsdir/${f##*/}" ] || /bin/ln -st $winfontsdir/ "$f"
done
/usr/bin/mkfontscale$winfontsdir
/usr/bin/mkfontdir $winfontsdir
# get cache file suffix currently -le64.cache-9 from latest fontconfig dll
dll=$(/bin/ls -rv /bin/cygfontconfig-*.dll | /usr/bin/head -n1)
suf=$(/bin/grep -Eao '[[:graph:]]*\.cache-[[:graph:]]+' $dll)
# cleanup cache every install - can become 100k+ files using GBs
/bin/rm -f $cache/*$suf
/usr/bin/find $cache -iname "*$suf" -delete
# reset and cache system dirs
/usr/libexec/fc-cache-1 -rs || :
# ensure TAG later for cleanup cron job
/usr/bin/touch -c $cache/CACHEDIR.TAG
lynx 2.9.1 available
Package lynx seems to have moved on from lynx.browser.org which is outdated at
2.8.8, to lynx.invisible-island.net where 2.9.1 is the latest stable release
following on from 2.9.0:
https://lynx.invisible-island.net/index.html
https://lynx.invisible-island.net/lynx.html
https://lynx.invisible-island.net/release/index.html
https://invisible-island.net/archives/lynx/tarballs/\
lynx2.9.1.tar.bz2{,.asc}
https://github.com/ThomasDickey/lynx-snapshots/tags
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: calm: vaulting ancient unifont
Thanks Jon? - yay! On 2024-05-04 09:48, cygwin-no-re...@cygwin.com wrote: INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz INFO: vaulting x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz INFO: vaulting x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz INFO: vaulting x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint INFO: vaulting x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz SUMMARY: 8 INFO(s) -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [ITA] bash-completion/-devel
On 2024-05-03 07:40, Jon Turney via Cygwin-apps wrote:
On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which was
adopted by Eric but not updated since Yaakov.
Thanks.
I added this to your packages.
Thanks Jon
I guess I need to ask eblake if he wants to orphan his packages, since he seems
to be no longer active...
Looks like he's busy with Austin Group POSIX + IEEE update plus work
Below are links to existing source packages, build repos, scallywag runs, and
updated package info.
I would like to further improve the sdesc and ldesc provided to reflect that
completions are provided for thousands of commands and their options and
arguments.
Bash Completions and development
Existing source package:
https://cygwin.com/packages/summary/bash-completion-src.html
Updated cygport:
https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground
A few comments:
DEPEND="automake dejagnu make screen" # tcllib
BUILD_REQUIRES="$DEPEND"
Just set BUILD_REQUIRES.
I assume the comment about tcllib means something to someone. :)
Checked Fedora spec for "advice" - required for testing - n/a on Cygwin
src_test() {
cd $B
# For some tests involving non-ASCII filenames
export LANG=C.UTF-8
export -f cygtest
# This stuff borrowed from dejagnu-1.4.4-17 (tests need a terminal)
tmpfile=$(mktemp bash-completion.screen.XX.tmp)
# cygtest
At first glance, because this is commented out, I thought "so this doesn't run
tests at all"
Maybe remove the commented out line, and write a comment saying something like
"run tests under screen, since they need a terminal"
screen -D -m bash -c '( cygtest ; echo $? ) >'$tmpfile
cat $tmpfile
result=$(tail -n 1 $tmpfile)
Also borrowed from Fedora spec.
Plan to do more comments and cleanup before merging to master.
They also had a ChangeLog generation problem so reported upstream and made my
own; they are trying a fix and update or may have a newer package release.
This cleverness to propagate the exit code is probably also worthy of comment,
since I had to think about it for a few minutes before I realized what it was
doing...
Perhaps should remove tmpfile here?
Must have deleted instead of commenting out!
return $result
}
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages
On 2024-04-30 23:32, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: Some package upstreams offer only checksums, for example .sha512sum, .sha256sum, for verification rather than gpg signatures, for example .asc, .sig, .sign, etc; use these checksum files when provided in a similar manner to gpg signatures; these files are often provided with fixed names which may be renamed on download to unique values using cygport URI fragment support like #/$NAME-VERSION.sha...sum; use coreutils cksum as it supports all modern and legacy checksums and formats. https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d Two similar independent implementations mean it would be a good idea to add the feature! Mine preferred cksum as being the most general approach, while not worrying or knowing too much about ancient sums, although your implementation is better, that is, works properly on those. Mine also preferred sha*sum file types, while still allowing prefixes only without sum, not enumerating them all in the unpack() case, and respecting the cksum crc default. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify
On 2024-04-30 23:50, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly, single operation gpg verification helper designed for use in scripts instead of gpg2 --verify: see 'info gpg2 helper gpgv' NAK. This tool doesn't check for expired keys and also searches for keys in different places, so you'd have to change your setup. More specifically you'd either have to explicitly trust all keys you want to check (not going to happen) or use a "--keyring" argument to force it to use the pubring. Questioning FMI but not disagreeing with your decision ;^> Not seeing any key issues as my pubring.gpg is symlinked as trustedkeys.gpg? Although scallywag runs can not even check keys, so what can we do about that? 2024-04-28T21:41:01.4042065Z >>> Preparing ncurses-6.5+20240427-1.x86_64 2024-04-28T21:41:01.4235798Z *** Info: SOURCE 1 signature follows: 2024-04-28T21:41:01.4407160Z gpg: directory '/home/runneradmin/.gnupg' created 2024-04-28T21:41:01.4508023Z gpg: keybox '/home/runneradmin/.gnupg/pubring.kbx' created 2024-04-28T21:41:01.4775748Z gpg: Signature made Sat, Apr 27, 2024 8:27:29 PM UTC 2024-04-28T21:41:01.4776513Z gpg:using RSA key 19882D92DDA4C400C22C0D56CC2AF4472167BE03 2024-04-28T21:41:01.4784503Z gpg: Can't check signature: No public key Other advantage is not seeing Eric Blake and others' pictures pop up ;^> I tested with all my cached signed upstream package downloads and compared the logs from gpg2 --verify and gpgv2, so what benefit is reporting trust level "[unknown]" and expired keys from cygport, and what are you meant to do about expired keys for upstream package signers? [While checking also came across keys from 1998 with my dialup email address!] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
[PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages
From: "Brian Inglis"
Some package upstreams offer only checksums, for example .sha512sum, .sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.
define __sum_verify() after __gpg_verify();
add to readonly function definition list
unpack(): skip files matching *.*sum
__src_prep():
define file types or prefixes in variable sum_exts;
in src files loop after __gpg_verify():
match file checksum type and call __sum_verify()
Signed-off-by: Brian Inglis
---
lib/src_prep.cygpart | 56
++-
1 file changed, 55 insertions(+), 1 deletion(-)
--- lib/src_prep.cygpart2024-01-15 05:09:23.0 -0700
+++ lib/src_prep.cygpart2024-04-30 11:41:01.218878400 -0600
@@ -88,6 +88,7 @@ unpack() {
# determine correct source decompression command
case ${unpack_file_path} in
*.asc|*.md5|*.sig|*.sign) continue ;;
+ *.*sum)continue ;;
*.tar.lrz)
check_prog_req lrzuntar lrzip
unpack_cmd="lrzuntar"
@@ -200,6 +201,43 @@ __gpg_verify() {
fi
}
+__sum_verify() {
+ local _file=${1#${DISTDIR}/};
+ local _filedesc=${2};
+ local _filetype=${3};
+ local _sum=${3%sum};
+
+ if ! check_prog cksum
+ then
+ # display notice only once
+ if ! defined _cksum_not_found_
+ then
+ inform "cksum must be installed in order to check
checksums.";
+ _cksum_not_found_=1
+ fi
+
+ return 0;
+ fi
+
+ # {b2,b2b}{,sum} -> blake2b; ck{,sum} -> crc; {,sum} -> bsd
+ [ -z "${_sum}" ]&& _sum=${_sum:-bsd}
+ [ "b2" = "${_sum}" ]&& _sum=blake2b
+ [ "b2b" = "${_sum}" ] && _sum=blake2b
+ [ "ck" = "${_sum}" ]&& _sum=crc
+
+ if defined DISTDIR && [ -d ${DISTDIR} ] && [ -f ${DISTDIR}/${_file} ]
+ then
+ cd ${DISTDIR}
+ inform "${_filedesc} ${_filetype} checksum verification
follows:";
+ if [ "${_sum}" = "crc" ] || [ "${_sum}" = "bsd" ] || [
"${_sum}" = "sysv" ]
+ then
+ cksum -a ${_sum} ${_file%.${_filetype}} || true;
+ else
+ cksum -a ${_sum} -c ${_file} || true;
+ fi
+ fi
+}
+
__mkdirs() {
cd ${top};
mkdir -p ${srcdir} ${origsrcdir} ${B} ${D} ${T} ${configdir} ${logdir}
${distdir} ${patchdir} ${spkgdir};
@@ -298,6 +336,10 @@ __src_prep() {
local src_pkg;
local tar_patch;
local n=1;
+ local sum_exts="sha512 sha384 sha256 sha224 b2 b2b blake2b sm3 sha1 md5
ck crc bsd sysv";
+ # prefer newer stronger keys for faster lookup
+ # blake2b bsd crc md5 sha1 sha224 sha256 sha384 sha512 sm3 sysv
+ # {b2,b2b}{,sum} -> blake2b; ck{,sum} -> crc; {,sum} -> bsd
cd ${top};
@@ -328,6 +370,18 @@ __src_prep() {
__gpg_verify ${src_pkg} "SOURCE $((n++))"
${sigext};
fi
done
+ for sigext in ${sum_exts} ''# final entry is BSD .sum -> ''
+ do
+ if [ "${src_pkg}" != "${src_pkg%.${sigext}sum}" ]
+ then
+ __sum_verify ${src_pkg} "SOURCE $((n++))"
"${sigext}sum";
+ break;
+ elif [ "${src_pkg}" != "${src_pkg%.${sigext}}" ] #
fail if '' unless *.
+ then
+ __sum_verify ${src_pkg} "SOURCE $((n++))"
"${sigext}";
+ break;
+ fi
+ done
done
for src_patch in ${_src_orig_patches}
@@ -510,4 +564,4 @@ __src_prep() {
}
readonly -f __cpio_gz_extract __gem_extract __srpm_extract unpack \
-__gpg_verify __mkdirs cygpatch __src_prep
+__gpg_verify __sum_verify __mkdirs cygpatch __src_prep
[PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify
From: "Brian Inglis"
Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
single operation gpg verification helper designed for use in scripts
instead of gpg2 --verify: see 'info gpg2 helper gpgv'
__gpg_verify(): use gpgv2 not gpg2 --verify
Signed-off-by: Brian Inglis
---
lib/src_prep.cygpart |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/lib/src_prep.cygpart 2024-01-15 05:09:23.0 -0700
+++ b/lib/src_prep.cygpart 2024-04-30 01:49:54.294030400 -0600
@@ -181,7 +181,7 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
- if ! check_prog gpg2
+ if ! check_prog gpgv2
then
# display notice only once
if ! defined _gpg_not_found_
@@ -196,7 +196,7 @@ __gpg_verify() {
if [ -f ${_file}.${_sigext} ]
then
inform "${_filetype} signature follows:";
- gpg2 --verify ${_file}.${_sigext} ${_file} || true;
+ gpgv2 ${_file}.${_sigext} ${_file} || true;
fi
}
Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable
On 2024-04-30 15:07, Christian Franke via Cygwin-apps wrote: Brian Inglis via Cygwin-apps wrote: On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote: The new script uses the SPDX webpages to create the license file. I didn't find a usable single license list at https://github.com/spdx As usual, it is easier if you clearly state the purpose of the file you want, and its desired properties, like data content, format, etc. What about: https://spdx.github.io/license-list-data/ This is apparently a draft version of https://spdx.org/licenses/index.html which is used by the script to generate the local license file. Strip out the table entries and create what you want with a command or script. and everything under: https://github.com/spdx/license-list-data I didn't find a single file which lists the licenses there. GH does not always make access easy, with its limited online displays and fixed display orders, and searches return a lot of junk, without easy access to better searching in context, but try: https://github.com/spdx/license-list-data/blob/main/licenses.md which also has xrefs to the text files; also there are: https://github.com/spdx/license-list-data/blob/main/json/licenses.json https://github.com/spdx/license-list-data/blob/main/json/exceptions.json which can be easily processed using `jq`. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable
On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote: Jon Turney via Cygwin-apps wrote: PS: I have a local script which checks SPDX Identifiers and expressions. Any interest to add this to cygport and then check LICENSE settings? Oh, yes please. That sounds like a good idea. Attached. The new script uses the SPDX webpages to create the license file. I didn't find a usable single license list at https://github.com/spdx What about: https://spdx.github.io/license-list-data/ and everything under: https://github.com/spdx/license-list-data The data/spdx-licenses file is not included in the patch. It could be generated from the source dir with: $ tools/spdx-check -f data/spdx-licenses -m ... data/spdx-licenses: created $ sha1sum data/spdx-licenses 80a19d6891d08bf34113464464ee12308374c792 *data/spdx-licenses The changes to the meson files are guessed. I didn't test the meson build yet. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
[ITA] bash-completion/-devel
I would like to co-maintain or adopt and revive the above package, which was adopted by Eric but not updated since Yaakov. Below are links to existing source packages, build repos, scallywag runs, and updated package info. I would like to further improve the sdesc and ldesc provided to reflect that completions are provided for thousands of commands and their options and arguments. Bash Completions and development Existing source package: https://cygwin.com/packages/summary/bash-completion-src.html Updated cygport: https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground Scallywag runs: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=bash-completion Bash Completions and development bash-completion is a collection of shell functions that use the programmable completion feature of bash. For more information see the project home page: https://github.com/scop/bash-completion See below for details of changes: https://github.com/scop/bash-completion/blob/master/CHANGELOG.md bash-completion Bash Completions Existing package: https://cygwin.com/packages/summary/bash-completion.html bash-completion-devel Bash Completions (development) Existing package: https://cygwin.com/packages/summary/bash-completion-devel.html
Re: |FILE_ID_BOTH_DIR_INFORMATION| fields |ShortName|+|ShortNameLength| mandatory for Cygwin and Window 10 ?
On 2024-04-27 07:08, Roland Mainz via Cygwin wrote:
Are the |FILE_ID_BOTH_DIR_INFORMATION| fields
|ShortName|+|ShortNameLength| mandatory these days, e.g. is it legal
to set |ShortNameLength = 0;| for Cygwin 3.4/3.5 in Windows 10 ?
MS Windows 8/Server 2012+ disabled 8.3 short name generation on new
volumes/partitions, for example see:
https://ss64.com/nt/syntax-filenames.html
https://archive.techarp.com/showarticle53b4.html?artno=827
https://learn.microsoft.com/en-ca/archive/blogs/josebda/windows-server-2012-file-server-tip-disable-8-3-naming-and-strip-those-short-names-too
https://learn.microsoft.com/en-ca/windows-server/administration/windows-commands/fsutil-8dot3name
This really makes a big difference on directories like /var/log/ and /tmp/ if
apps create a lot of files with similar name prefixes there, for example,
date/time suffixed long file names from multiple hourly cron jobs, as long names
can be queried via the B-tree but short names have to be scanned sequentially.
Is there anything else for a filesystem driver to do to indicate that
|ShortName| support is not available ?
Also see fsutil behavior query|set disable8dot3 [[ [{1|0}]]|]
% fsutil 8dot3name set /?
usage : fsutil 8dot3name set [0 through 3] | [ 1 | 0]
When a volume is not specified the operation updates the registry value:
0 - Enable 8dot3 name creation on all volumes on the system
1 - Disable 8dot3 name creation on all volumes on the system
2 - Set 8dot3 name creation on a per volume basis
3 - Disable 8dot3 name creation on all volumes except the
system volume
When a volume is specified the operation updates the individual
volume's on disk flag. This operation is only meaningful
if the registry value is set to 2.
0 - Enable 8dot3 name creation on this volume
1 - Disable 8dot3 name creation on this volume
This operation takes effect immediately (no reboot required).
Sample commands:
"fsutil 8dot3name set 1" - disable 8dot3 name creation on all volumes
"fsutil 8dot3name set C: 1" - disable 8dot3 name creation on c:
% regtool get -v
/proc/registry/HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/FileSystem/NtfsDisable8dot3NameCreation
2
% fsutil 8dot3name query c:
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2 (Per volume setting - the default).
Based on the above settings, 8dot3 name creation is enabled on c:
% fsutil 8dot3name query d:
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2 (Per volume setting - the default).
Based on the above settings, 8dot3 name creation is enabled on d:
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: DOS namespaces, accessible/walk-able as Admin via Cygwin?
On 2024-04-25 19:45, Dan Shelton via Cygwin wrote: On Mon, 22 Apr 2024 at 07:01, Brian Inglis via Cygwin wrote: On 2024-04-21 17:24, Dan Shelton via Cygwin wrote: On Sat, 20 Apr 2024 at 05:37, Brian Inglis via Cygwin wrote: 2. If I have Administrator rights, is there a way in /proc where I can /bin/ls -la or /bin/find -ls all those DOS namespaces and soft links to the real devices? Cygwin exposes these MS Windows Executive Object Manager subsystem resource objects under /proc/sys/ and object namespaces are per session under /proc/sys/Sessions/ you have e.g. $ ls -glo /proc/sys/Sessions/BNOLINKS/ total 0 lr--r--r-- 1 0 Apr 19 21:23 0 -> /proc/sys/BaseNamedObjects lr--r--r-- 1 0 Apr 19 21:23 1 -> /proc/sys/Sessions/1/BaseNamedObjects so each session has its own set of BaseNamedObjects, which you can list with appropriate permissions, or using a tree browser. Now where does the "1" in /proc/sys/Sessions/1/BaseNamedObjects come from? Is there a Cygwin or Win32 API for that? It's the MS Windows session number for the first user session. You can access them using Cygwin or MS Windows directory lookups or tree browsers, as I said. Search microsoft.com for Windows sessions for details about MS Windows APIs. Windows has multiple session apis (terminal, logon, ...), which is used for the DOS namespace? There really does not appear to be a "DOS" namespace, rather there are a bunch of legacy object names in the namespaces which may be used by console and GUI programs to access and operate on the underlying objects, possibly also using legacy APIs. Under MS Windows you can use Sysinternals WinObj64 to browse the hierarchy and objects. What is that? If you do not yet know that, perhaps you should not yet be digging into these MS Windows Executive subsystem objects. Some of these questions seem very abstract - are these academic questions or projects? Building knowledge, learning, and debugging actual code. Have a look at the object hierarchies either using a Cygwin tree browser or the winobj64 object browser to see what is actually out there and their properties. The Cygwin all-volunteer spare time project's interest is in using newlib libc and Windows APIs to provide Unix functionality, to relevant POSIX standards if available and appropriate. For anything else you should consult the available project documentation in the cygwin-doc package or online, in the newlib-cygwin/winsup/cygwin C++ source code providing the emulation, any MS Windows documentation that the vendor cares to make available, and perhaps other MS Windows emulation based open source projects like Wine, mingw64, msys2, 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygrunserv: sc config start=boot supported?
On 2024-04-25 19:54, Dan Shelton via Cygwin wrote: Does Cygwin cygrunserv support the start mode start=boot? Please install the packages cygwin-doc and cygrunsrv, and read the User Guide, the FAQ, the API docs, and the relevant program manual page, or search and read the online versions e.g. https://cygwin.com/git/?p=newlib-cygwin.git=search=HEAD=pickaxe=cygrunsrv and the underlying files referenced for more information. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [Question] When the cygwin support Python version 3.11.5 or newer?
On 2024-04-21 18:25, Zhike Wang via Cygwin wrote:
Any update/advice for this topic? Or should I raise a ticket to other Cygwin
Mailing Lists?
There are no tickets and no other lists - this is the list for Cygwin issues.
On April 18, 2024 20:29, Zhike Wang wrote:
At the moment, I use python 3.9.16 under Cygwin environment while my
company IT alert me there is a severity risk for python 3.9.16 which need
be upgraded to Python version 3.11.5 or newer asap.
I have tried to use Cygwin setup(setup-x86_64) to update the python version
but it looks Cygwin only support python up to version 3.9.18 at the
moment.
So I would like to check with experts when the Cygwin can support Python
3.11.5 or newer version?
Thank you very much.
It appears that this is not how python is maintained, as all python modules and
packages have to be rebuilt for each major version, so fixes are applied to each
supported major version e.g 3.9!
The web page below is more useful as it shows the current latest python release
with all known core vulnerabilities fixed for each major version:
https://maikuolan.github.io/Vulnerability-Charts/python.html
for a few other packages see:
https://maikuolan.github.io/Vulnerability-Charts/
https://github.com/Maikuolan/Vulnerability-Charts
so 3.{8,9}.19+ should fix all currently known security issues with 3.{8,9};
other releases are required for newer versions.
And 3.11.5 has issues, 3.11.9 is fixed: let your co IT know this!
Please note also that some vulnerabilities are specific to only certain
platforms and capabilities e.g. Linux:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42919
https://nvd.nist.gov/vuln/detail/CVE-2022-42919
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: /usr/bin/sg in Cygwin?
On 2024-04-21 23:35, Cedric Blancher via Cygwin wrote: Good morning! On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin wrote: On 2024-04-19 17:47, Dan Shelton via Cygwin wrote: On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote: Is there a package which provides /usr/bin/sg (execute shell commands in a different group)? The POSIX standard command is newgrp - install cygwin-doc to see Cygwin (and newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see POSIX man pages, and man-pages-linux if you want to see recent Linux release man pages. Debian /usr/bin/sg (setgid analog to /usr/bin/su) comes from the package "login" (https://packages.debian.org/bookworm/login), same package as /usr/bin/newgrp. So maybe it just needs to be packaged by whoever owns the Cygwin package for /usr/bin/newgrp? The Linux package is all about PAM hooks and other Linux stuff. As with BSD, login authentication is delegated to the underlying OS, in this case MS Windows, so any such utilities have to be rewritten, using the underlying emulation or OS access layers, or additions to them. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: DOS namespaces, accessible/walk-able as Admin via Cygwin?
On 2024-04-21 17:24, Dan Shelton via Cygwin wrote: On Sat, 20 Apr 2024 at 05:37, Brian Inglis via Cygwin wrote: On 2024-04-19 17:09, Dan Shelton via Cygwin wrote: 1. Windows has DOS namespaces per user, or per Logon. Can anyone explain this from a Win32 API point of view how they are kept separate? Ask on SuperUser *NOT* SO! I cannot follow you. What should I do? You asked the same question on StackOverflow group and was told that was not the appropriate group - SuperUser is the appropriate StackOverflow group. 2. If I have Administrator rights, is there a way in /proc where I can /bin/ls -la or /bin/find -ls all those DOS namespaces and soft links to the real devices? Cygwin exposes these MS Windows Executive Object Manager subsystem resource objects under /proc/sys/ and object namespaces are per session under /proc/sys/Sessions/ you have e.g. $ ls -glo /proc/sys/Sessions/BNOLINKS/ total 0 lr--r--r-- 1 0 Apr 19 21:23 0 -> /proc/sys/BaseNamedObjects lr--r--r-- 1 0 Apr 19 21:23 1 -> /proc/sys/Sessions/1/BaseNamedObjects so each session has its own set of BaseNamedObjects, which you can list with appropriate permissions, or using a tree browser. Now where does the "1" in /proc/sys/Sessions/1/BaseNamedObjects come from? Is there a Cygwin or Win32 API for that? It's the MS Windows session number for the first user session. You can access them using Cygwin or MS Windows directory lookups or tree browsers, as I said. Search microsoft.com for Windows sessions for details about MS Windows APIs. Under MS Windows you can use Sysinternals WinObj64 to browse the hierarchy and objects. What is that? If you do not yet know that, perhaps you should not yet be digging into these MS Windows Executive subsystem objects. Some of these questions seem very abstract - are these academic questions or projects? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygrunsrv: trailing command line arguments not allowed
On 2024-04-20 06:31, Eliot Moss via Cygwin wrote:
On 4/20/2024 8:12 AM, enrique--- via Cygwin wrote:
Hello,
I am trying to install a service manually in an attempt to understand why
cron-config did not work for me.
So, I did this:
$ net stop cron
Tjenesten Cron daemon stopper .
Tjenesten Cron daemon ble stoppet.
$ cygrunsrv -R cron
$ cygrunsrv -I -p /usr/sbin/cron.exe -a -n
cygrunsrv: Trailing commandline arguments not allowed
Try `cygrunsrv --help' for more information.
I also tried a number of other combinations and orders of arguments, all with
similar results.
What am I doing wrong?
I would try --args '-n' instead of -a -n. Perhaps some other
variation of quoting will be needed to make clear to cygrunsrv
that the -n is for the application, not for cygrunsrv.
Unadorned options anywhere on the command line are parsed by getopt, which is
why the options are quoted by cron-config:
$ awk '/cygrunsrv\s-I/,/[^\\]$/' /usr/bin/cron-config
if cygrunsrv -I cron -p /usr/sbin/cron -e CYGWIN="${cygenv}" -e
TMP="/tmp" \
-e TEMP="/tmp" -a "-n" -d "Cron daemon" -u "$cyg_username"
-w "$password"
if cygrunsrv -I cron -p /usr/sbin/cron -e CYGWIN="${cygenv}" \
-a "-n" -d "Cron daemon"
I have normally found it more useful to run Cygwin *-config as elevated admin,
and if from cmd with Cygwin /bin/ in path, then as `bash -c /usr/bin/*-config`.
You can modify settings either with:
$ cygrunsrv -E $srv; cygrunsrv -R $srv; cygrunsrv -I $srv ...
possibly adding:
-d, --disp "CYGWIN Cron daemon"
-c, --chdir `cygpath -m /`
-O, --preshutdown
-y, --dep syslog-ng ...
or with:
$ sc config help
DESCRIPTION:
Modifies a service entry in the registry and Service Database.
USAGE:
sc config [service name] ...
OPTIONS:
NOTE: The option name includes the equal sign.
A space is required between the equal sign and the value.
To remove the dependency, use a single / as dependency value.
type=
start=
error=
binPath=
group=
tag=
depend=
obj=
DisplayName=
password=
for example:
$ sc cron config start= delayed-auto DisplayName= "CYGWIN Cron daemon" \
depend= syslog-ng
or
$ s=/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cron; \
regtool set -d $s/KEY DWORD-VALUE; \
...
giving something like:
$ s=/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cron; \
for p in {'',/Parameters{,/Environment}}; do \
echo; echo $s$p:; regtool list -v $s$p;
done
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cron:
Parameters/ ()
DisplayName (REG_SZ) = "CYGWIN Cron daemon"
Type (REG_DWORD) = 0x0010 (16)
Start (REG_DWORD) = 0x0002 (2)
ErrorControl (REG_DWORD) = 0x0001 (1)
ImagePath (REG_EXPAND_SZ) = ".../bin/cygrunsrv.exe"
ObjectName (REG_SZ) = "LocalSystem"
Description (REG_SZ) = "Cygwin Command Execution Scheduler cron daemon"
DelayedAutoStart (REG_DWORD) = 0x0001 (1)
DependOnService (REG_MULTI_SZ) = "syslog-ng"
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cron/Parameters:
Environment/ ()
AppPath (REG_SZ) = "/usr/sbin/cron"
AppArgs (REG_SZ) = "-n"
Preshutdown (REG_DWORD) = 0x0001 (1)
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/cron/Parameters/Environment:
CYGWIN (REG_SZ) = " "
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: /usr/bin/sg in Cygwin?
On 2024-04-19 17:47, Dan Shelton via Cygwin wrote: On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote: Is there a package which provides /usr/bin/sg (execute shell commands in a different group)? The POSIX standard command is newgrp - install cygwin-doc to see Cygwin (and newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see POSIX man pages, and man-pages-linux if you want to see recent Linux release man pages. To see possibly relevant commands, run: $ apropos -s 1,1p group chgrp (1)- change group ownership chgrp (1p) - change the file group ownership chown (1)- change file owner and group g3topbm (1) - convert a Group 3 fax file into a PBM image groups (1) - print the groups a user is in id (1) - print real and effective user and group IDs make (1) - GNU Make utility to maintain groups of programs make (1p)- maintain, update, and regenerate groups of programs mkgroup (1) - Write /etc/group-like output to stdout newgrp (1) - change primary group for a command newgrp (1p) - change to a new group pbmtog3 (1) - convert a PBM image into a Group 3 MH fax file -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: problem with make 4.4.1-2 or gcc-fortran 11.4.0-1
On 2024-04-19 15:39, René Berber via Cygwin wrote: On 4/19/2024 2:59 PM, Arnab Paul via Cygwin wrote: Hello, I am trying to install a software which requires the libraries gcc-fortran, make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git. As I did and ran the commands given below, git clone https://github.com/Aida-Alvera/DINEOF cd DINEOF/ cp config.mk.template config.mk make The make command is showing the problem as Makefile:30: Compilers/Windows_NT-gfortran.mk: No such file or directory make: *** No rule to make target 'Compilers/Windows_NT-gfortran.mk'. Stop. I am keeping Linux as my default OS but it is asking for the Windows_NT-gfortran.mk Looking at the Makefile, lines 13 to 15, and 30: The problem is that Makefile optionally sets OS to Linux (line 13) but in Cygwin OS is set to Windows_NT. i.e. $ echo $OS Windows_NT The solution is to change that environment variable. There are several ways try correct that, try: make OS=Linux Better - first try: $ uname -o Cygwin but Linux shows *GNU/Linux*, so then try e.g.: $ uname -s Linux and only then see if $OS is defined and use it. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: DOS namespaces, accessible/walk-able as Admin via Cygwin?
On 2024-04-19 17:09, Dan Shelton via Cygwin wrote: 1. Windows has DOS namespaces per user, or per Logon. Can anyone explain this from a Win32 API point of view how they are kept separate? Ask on SuperUser *NOT* SO! 2. If I have Administrator rights, is there a way in /proc where I can /bin/ls -la or /bin/find -ls all those DOS namespaces and soft links to the real devices? Cygwin exposes these MS Windows Executive Object Manager subsystem resource objects under /proc/sys/ and object namespaces are per session under /proc/sys/Sessions/ you have e.g. $ ls -glo /proc/sys/Sessions/BNOLINKS/ total 0 lr--r--r-- 1 0 Apr 19 21:23 0 -> /proc/sys/BaseNamedObjects lr--r--r-- 1 0 Apr 19 21:23 1 -> /proc/sys/Sessions/1/BaseNamedObjects so each session has its own set of BaseNamedObjects, which you can list with appropriate permissions, or using a tree browser. Under MS Windows you can use Sysinternals WinObj64 to browse the hierarchy and objects. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Howto request an upgrade for keychain package
On 2024-04-19 08:53, J M via Cygwin wrote: El jue., 18 abr. 2024 20:10, J M escribió: I'm having some problems (gpg2, and some for ssh management) with keychain package: https://www.cygwin.com/packages/summary/keychain.html It version is 2.7.1, can be upgraded to, by example the last 2.8.5? It is here: https://github.com/funtoo/keychain/tree/2.8.5 Fow now, I implement a very weird implementation to fix this (very old keychain version) in pseudocode: If I am inside Cygwin and keychain version is 2.7.1 then: curl -L -o /usr/bin/keychain https://raw.githubusercontent.com/funtoo/keychain/2.8.5/keychain But it is a weird workaround, you can upgrade this package? If not exists any security problem clearly... The upstream repo has not been updated since 2018. You might be better finding a more modern, secure, compatible login manager like gnome-keyring or KDE kwalletmanager, or improved process like using known hosts and authorized keys files to limit access. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Let's Encrypt Dropping Cross-Signed Root and Intermediates; Issuing New Intermediates; New Cert Chains
Unsure of impact and action required was why I posted - Cygwin, Sourceware, GNU, Kernel.org, etc. use LE certs. Looks like new root and/or intermediate certs are available to be packaged before they will be used 2024 June 6 and old cross-signed root if included may be removed before 2024 Sep 30. Seems that outdated Android versions will no longer work as before on LE certified sites, but probably others have also changed by now. On 2024-04-19 06:48, Jon Turney via Cygwin-apps wrote: On 17/04/2024 04:48, Brian Inglis via Cygwin-apps wrote: Is this FYI, or are you suggesting there is some specific action we need to take? https://letsencrypt.org/2023/07/10/cross-sign-expiration Shortening the Let's Encrypt Chain of Trust "On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in requests made to our /acme/certificate API endpoint. On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. On Monday, September 30th, 2024, the cross-signed certificate will expire." https://letsencrypt.org/2024/03/19/new-intermediate-certificates New Intermediate Certificates "Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new Intermediate CA Certificates containing the new public keys." https://letsencrypt.org/2024/04/12/changes-to-issuance-chains Deploying Let's Encrypt's New Issuance Chains "On Thursday, June 6th, 2024, we will be switching issuance to use our new intermediate certificates. Simultaneously, we are removing the DST Root CA X3 cross-sign from our API, aligning with our strategy to shorten the Let’s Encrypt chain of trust. We will begin issuing ECDSA end-entity certificates from a default chain that just contains a single ECDSA intermediate, removing a second intermediate and the option to issue an ECDSA end-entity certificate from an RSA intermediate." -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: calm: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate
On 2024-04-17 13:37, Jon Turney via Cygwin-apps wrote: On 17/04/2024 15:17, Brian Inglis via Cygwin-apps wrote: On 2024-04-17 07:08, cygwin-no-reply wrote: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate This is the "change things to that the geoipupdate package belongs to GeoIP-database source" I previously mentioned. I've done that, and the upload seems to have succeeded. I also fixed a typo I noticed in the geoipupdate DESCRIPTION: - THe geoipupdate database updater script downloads the latest available + The geoipupdate database updater script downloads the latest available Thanks Jon, I also noticed that offline, committed, merged to master, and pushed. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [ITA] GeoIP, GeoIP-database, geoipupdate
On 2024-04-17 13:38, Jon Turney via Cygwin-apps wrote:
On 17/04/2024 00:39, Brian Inglis via Cygwin-apps wrote:
On 2024-04-16 13:31, Jon Turney via Cygwin-apps wrote:
On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last
("unofficial") version of the legacy code committed noted in the ChangeLog
as 1.7.0, and a new upstream source for legacy format free databases
converted when the official current upstream databases are updated.
My very limited, vague understanding was that GeoIP is obsolete and users
should move to something newer? What packages do we have that actually depend
on this? Are there other ways to update them?
$ cygcheck-dep -nqS libGeoIP1 libmaxminddb0
libGeoIP1: is needed for ( GeoIP libdns1104 libdns1105 libdns166 libdns169
libGeoIP-devel )
libmaxminddb0: is needed for ( bind libdns1106 libmaxminddb-devel
lighttpd-mod_maxminddb )
Looks like older bind used free legacy GeoIP databases, "current" bind uses
current library and current GeoIP2 databases which require free registration
to get an API key with limits.
The new upstream source for free legacy GeoIP databases converts upstream
GeoIP2 databases and makes them available under its CC-by-4.0 licence.
The most recent bind package was built with '--without-geoip'. Does this need
to change back again?
It was built with libmaxminddb which requires the Maxmind API key registration
to download the free but not publicly available GeoLite2 and new geoipupdate
which can only download from new databases with the new API and registered key.
https://cygwin.com/packages/summary/libdns1106.html
https://geoip.site/ [another legacy alternative]
https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
This supports bind geoDNS applications like geo-[b]locking and geo-redirection.
$ cpm-sum libdns1{6{6,9},10{4,5,6}} | grep
'dns\|bind\|maxmind\|GeoIP\|depends:\|ackage:$'
Package: libdns166
depends:
cygwin, libGeoIP1, libgssapi_krb5_2, libisc160, libjson-c2, libkrb5_3,
rdepends:
dnsperf, libbind9_160, libirs160, libisccfg160
source package:
bind
I guess there's another thread to pull on here.
The code which looks for "old soversions we don't need to keep anymore" isn't
smart enough currently to realize that it can get rid of all of these old libdns
soversions.
Assuming that gets fixed (...), do we still have users?
The main user may still be the GeoIP binary package utilities geoiplookup/6.
I and presumably others use them in scripts to inform where sites and addresses
are likely geo or net located or distributed; for example:
$ geoiplookup sourceware.org
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, 00, N/A, N/A, N/A, 37.750999, -97.821999, 0, 0
GeoIP ASNum Edition: AS17314 REDHAT-HOSTED
$ geoiplookup redhat.com
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, VA, Virginia, Ashburn, 20149, 39.046902,
-77.490303, 511, 0
GeoIP ASNum Edition: AS14618 AMAZON-AES
$ geoiplookup ibm.com
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, WA, Washington, Seattle, 98160, 47.603401,
-122.341400, 819, 0
GeoIP ASNum Edition: AS16625 AKAMAI-AS
$ geoiplookup geoip.site
GeoIP Country Edition: US, United States
GeoIP City Edition, Rev 1: US, 00, N/A, N/A, N/A, 37.750999, -97.821999, 0, 0
GeoIP ASNum Edition: AS13335 CLOUDFLARENET
$ geoiplookup6 dronecode.org.uk
GeoIP Country V6 Edition: GB, United Kingdom
GeoIP ASNum V6 Edition: AS44684 Mythic Beasts Ltd
GeoIP City Edition V6, Rev 1: GB, 00, N/A, N/A, 51.496399, -0.122400, 0, 0
$ geoiplookup mythic-beasts.com
GeoIP Country Edition: GB, United Kingdom
GeoIP City Edition, Rev 1: GB, 00, N/A, N/A, N/A, 51.496399, -0.122400, 0, 0
GeoIP ASNum Edition: AS44684 Mythic Beasts Ltd
These show that sourceware, RedHat, IBM, and geoip.site all use CDNs; geoip.site
and dronecode (and RPi), are all hosted by Mythic Beasts, and their geoloc
places them in the Docklands at Millwall near two of their colos!
The accuracy radius (2nd last #) in km follows lat, long, but from often within
.01 of that value, e.g. 511 => ~5 actual ~3.3km from AWS US-East-1; 819 => ~8
actual ~2km from Seattle Colo with Equinix, Shaw(/Rogers), other colos, and
another ~600m from H5, and 1-15km from Cisco, Cyxtera, other SEA1.
These legacy files converted from Maxmind GeoLite2 sources appear to be somewhat
better than the previous Maxmind legacy GeoLite and CSV sources.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: calm: ERROR: Upload failed: cd: Access failed: No such file (/x86_64/release)
On 2024-04-17 14:15, Jon Turney via Cygwin-apps wrote: On 17/04/2024 20:26, Brian Inglis via Cygwin-apps wrote: Fairly straightforward upgrade of packages. Is anything demented about my setup: $ cygport GeoIP.cygport upload >>> Uploading GeoIP-1.7.0-1.x86_64 >>> Running lftp sftp://cygwin:@cygwin.com cd: Access failed: No such file (/x86_64/release) *** ERROR: Upload failed Thanks for reporting this. When I connect using `lftp sftp://cygwin` I now seem to be logged in to the sftp *root* instead of /home/Brian\ Inglis! But in future, if you are ever reporting "I think I have access to stuff on sourceware I shouldn't have access to", you may, exceptionally in that situation only, send me a private mail. Thanks Jon, Never occurred to me it was a security glitch, nor even to look around except in my own home dir, but I will try to remember to think that way, and let you or someone know quietly in future. Did sysadmin work long enough to have little interest now, except when unable to do something admin would allow, and have to ask someone ;^> Or is this just a way to allow my GeoIP... updates to be fixed up before I can do anything more? This was the result of a sshd configuration error which has been rectified by sourceware overseers. Oops! Glad I noticed and mentioned that, rather than just wait and see if it was rectified: don't want to be (much of) a pain, but you never know, as here. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: tzdata bug?
nfo/Europe/London 0e15: 4c 4d 54 00 42 53 54 00 47 4d 54 00 42 44 53 54 LMT.BST.GMT.BDST 0e25: 00 . $ xxd -s 0xe26 -l 0x10 -g1 /usr/share/zoneinfo/Europe/London 0e26: 00 01 01 01 00 00 01 01 00 00 00 00 00 00 01 01 $ xxd -s 0xe36 -l 0x1a -g1 /usr/share/zoneinfo/Europe/London 0e36: 0a 47 4d 54 30 42 53 54 2c 4d 33 2e 35 2e 30 2f .GMT0BST,M3.5.0/ 0e46: 31 2c 4d 31 30 2e 35 2e 30 0a1,M10.5.0. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
calm: ERROR: Upload failed: cd: Access failed: No such file (/x86_64/release)
Hi folks, Fairly straightforward upgrade of packages. Is anything demented about my setup: $ cygport GeoIP.cygport upload >>> Uploading GeoIP-1.7.0-1.x86_64 >>> Running lftp sftp://cygwin:@cygwin.com cd: Access failed: No such file (/x86_64/release) *** ERROR: Upload failed When I connect using `lftp sftp://cygwin` I now seem to be logged in to the sftp *root* instead of /home/Brian\ Inglis! Or is this just a way to allow my GeoIP... updates to be fixed up before I can do anything more? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: calm: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate
On 2024-04-17 07:08, cygwin-no-re...@cygwin.com wrote: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate ERROR: error while merging uploaded x86_64 packages for Brian Inglis SUMMARY: 2 ERROR(s) Hi folks/Jon, Replacing obsolete compiled geoipupdate package with script subpackage which obsoletes the previous geoipupdate-debuginfo. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Let's Encrypt Dropping Cross-Signed Root and Intermediates; Issuing New Intermediates; New Cert Chains
Hi folks, https://letsencrypt.org/2023/07/10/cross-sign-expiration Shortening the Let's Encrypt Chain of Trust "On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in requests made to our /acme/certificate API endpoint. On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. On Monday, September 30th, 2024, the cross-signed certificate will expire." https://letsencrypt.org/2024/03/19/new-intermediate-certificates New Intermediate Certificates "Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new Intermediate CA Certificates containing the new public keys." https://letsencrypt.org/2024/04/12/changes-to-issuance-chains Deploying Let's Encrypt's New Issuance Chains "On Thursday, June 6th, 2024, we will be switching issuance to use our new intermediate certificates. Simultaneously, we are removing the DST Root CA X3 cross-sign from our API, aligning with our strategy to shorten the Let’s Encrypt chain of trust. We will begin issuing ECDSA end-entity certificates from a default chain that just contains a single ECDSA intermediate, removing a second intermediate and the option to issue an ECDSA end-entity certificate from an RSA intermediate." -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: [ITA] GeoIP, GeoIP-database, geoipupdate
On 2024-04-16 13:31, Jon Turney via Cygwin-apps wrote:
On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last
("unofficial") version of the legacy code committed noted in the ChangeLog as
1.7.0, and a new upstream source for legacy format free databases converted
when the official current upstream databases are updated.
My very limited, vague understanding was that GeoIP is obsolete and users should
move to something newer? What packages do we have that actually depend on this?
Are there other ways to update them?
$ cygcheck-dep -nqS libGeoIP1 libmaxminddb0
libGeoIP1: is needed for ( GeoIP libdns1104 libdns1105 libdns166 libdns169
libGeoIP-devel )
libmaxminddb0: is needed for ( bind libdns1106 libmaxminddb-devel
lighttpd-mod_maxminddb )
Looks like older bind used free legacy GeoIP databases, "current" bind uses
current library and current GeoIP2 databases which require free registration to
get an API key with limits.
The new upstream source for free legacy GeoIP databases converts upstream GeoIP2
databases and makes them available under its CC-by-4.0 licence.
$ cpm-sum libdns1{6{6,9},10{4,5,6}} | grep
'dns\|bind\|maxmind\|GeoIP\|depends:\|ackage:$'
Package: libdns166
depends:
cygwin, libGeoIP1, libgssapi_krb5_2, libisc160, libjson-c2, libkrb5_3,
rdepends:
dnsperf, libbind9_160, libirs160, libisccfg160
source package:
bind
Package: libdns169
depends:
cygwin, libGeoIP1, libgssapi_krb5_2, libisc166, libjson-c2, libkrb5_3,
rdepends:
dnsperf, libbind9_160, libirs160, libisccfg160
source package:
bind
Package: libdns1104
depends:
cygwin, libGeoIP1, libgssapi_krb5_2, libisc1100, libjson-c2, libkrb5_3,
rdepends:
bind, bind-utils, libbind9-devel, libbind9_161, libirs161, libisccfg163
source package:
bind
Package: libdns1105
depends:
cygwin, libGeoIP1, libgssapi_krb5_2, libisc1100, libjson-c2, libkrb5_3,
rdepends:
bind, bind-utils, libbind9-devel, libbind9_161, libirs161, libisccfg163
source package:
bind
Package: libdns1106
depends:
libmaxminddb0, libssl1.1, libxml2
rdepends:
bind, bind-utils, dnsperf, libbind9-devel, libbind9_161, libirs161,
source package:
bind
Is there any easy way of overridding package version from
ac_init_version without patching configure.ac?
Generally, no.
Tried the obvious stuff with no effect, so applied patch.
As part of this upgrade, the geoipupdate source and databases are no longer
available, so the new upstream database source update script becomes a new
database subpackage and script geoipupdate, and the old geoipupdate source,
binary, and debuginfo packages should become obsolete.
Is there anything special required to replace a source package and binaries
with a binary subpackage?
Uh... I had to reread that several times (and compare with the cygport) before
it this question made sense.
So: when you come to upload, I'll need to change things to that the geoipupdate
package belongs to GeoIP-database source.
geoipupdate should probably obsolete geoipupdate-debuginfo, if it's now empty.
Good point, thanks.
Reviewing the cygports, everything looks OK.
I'd make the comment that the text about scheduling geoipupdate to run should be
in geoipupdate_DESCRIPTION, rather than in GeopIP-database's description.
Good point, I will rework some info.
I added GeoIP and GeoIP-database to your packages.
Cheers, thanks!
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: package update announcements not being accepted or forwarded?
On 2024-04-14 21:16, gs-cygwin@gluelogic.com wrote: On Sun, Apr 14, 2024 at 04:08:25PM -0600, Brian Inglis via Cygwin-apps wrote: I sent an announcement for *cpuid* after the fixes, which appears to have made it into the inbox and archives, but I did not see it and neither has mail-archive, so resent the announcement. Has anyone else received that announcement for *cpuid* on the list? FYI: I *have not* seen it, though I did get this message from you. Thanks Glenn, I think my mistake was resending with the same date and message id, which inbox uses as a key, and archives seems to have interpreted as a follow-up to mosh announcement? Trying a resend with updated date and message-id! Cheers! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
package update announcements not being accepted or forwarded?
Hi folks, I sent an announcement for *cpuid* after the fixes, which appears to have made it into the inbox and archives, but I did not see it and neither has mail-archive, so resent the announcement. Has anyone else received that announcement for *cpuid* on the list? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: package uploads not being processed again - calm failed or stuck?
On 2024-04-14 15:10, Jon Turney via Cygwin-apps wrote: On 14/04/2024 22:01, Brian Inglis via Cygwin-apps wrote: On 2024-04-14 13:53, Brian Inglis via Cygwin-apps wrote: Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? `ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ command to show us what calm is doing! Sorry, this isn't going to happen for various reasons. Achim - none of your announced releases appear to have been processed yet! Thanks to whoever got the process going again a half hour ago! I could see from curl -I the setup.ini last-modified date updated. No problem. sourceware overseers have re-arranged things so it won't be automatically killed by systemd for lols, and I am assured it should carry on running now... Some emails reporting uploads that had been processed have been lost during the confusion. We apologize for the inconvenience. Thanks Jon, No need for apologies from you - overseers should have systemd email apologies to the appropriate mailing list(s) when daemon services have to be restarted after systemd has decided they no longer need to be running ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: package uploads not being processed again - calm failed or stuck?
On 2024-04-14 13:53, Brian Inglis via Cygwin-apps wrote: Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? `ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ command to show us what calm is doing! Achim - none of your announced releases appear to have been processed yet! Thanks to whoever got the process going again a half hour ago! I could see from curl -I the setup.ini last-modified date updated. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
package uploads not being processed again - calm failed or stuck?
Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? `ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ command to show us what calm is doing! Achim - none of your announced releases appear to have been processed yet! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: package uploads not being processed - calm failed or stuck?
On 2024-04-13 14:34, Jon Turney via Cygwin-apps wrote: On 13/04/2024 21:12, Brian Inglis via Cygwin-apps wrote: Hi folks, Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? Thanks for the report. Not sure what went wrong there, but I've restarted it and it seems to have processed all the pending uploads. Thanks Jon, Hopefully there is something in some log that can help you figure out the cause. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: package uploads not being processed - calm failed or stuck?
On 2024-04-13 14:12, Brian Inglis via Cygwin-apps wrote: Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? `ssh` commands /help/, /alive/, /info/ work okay - could do with a /status/ command to show us what calm is doing? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
package uploads not being processed - calm failed or stuck?
Hi folks, Not seeing any progress hours after package upload - master setup.ini not updated and no calm emails received - has calm failed or is it stuck? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
[ITA] GeoIP, GeoIP-database, geoipupdate
I would like to adopt and revive the above packages with the last ("unofficial")
version of the legacy code committed noted in the ChangeLog as 1.7.0, and a new
upstream source for legacy format free databases converted when the official
current upstream databases are updated.
Is there any easy way of overridding package version from
ac_init_version without patching configure.ac?
As part of this upgrade, the geoipupdate source and databases are no longer
available, so the new upstream database source update script becomes a new
database subpackage and script geoipupdate, and the old geoipupdate source,
binary, and debuginfo packages should become obsolete.
Is there anything special required to replace a source package and binaries with
a binary subpackage?
Below are links to existing source packages, build repos, scallywag runs, and
updated package info.
Geographic IP Lookup utilities, development, and runtime
Existing source package:
https://cygwin.com/packages/summary/GeoIP-src.html
Updated cygport:
https://cygwin.com/cgit/cygwin-packages/GeoIP/tree/GeoIP.cygport?h=playground
Scallywag runs:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP
Geographic IP Lookup utilities, development, and runtime
GeoIP finds geographic and network locations of an IP address.
For more information see the project home page:
https://github.com/maxmind/geoip-api-c
See below for details of changes:
https://github.com/maxmind/geoip-api-c/blob/master/ChangeLog
GeoIP-database Geographic IP Lookup (databases)
Existing source package:
https://cygwin.com/packages/summary/GeoIP-database-src.html
Updated cygport:
https://cygwin.com/cgit/cygwin-packages/GeoIP-database/tree/?h=playground
Scallywag runs:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP-database
GeoIP-database Geographic IP Lookup (databases)
GeoIP finds geographic and network locations of an IP address.
These databases are extracts of free GeoLite2 data from Maxmind
https://www.maxmind.com/ and are less accurate than the commercial databases.
geoipupdate Geographic IP Lookup (database update utility)
geoipupdate database updater script downloads the latest available data
and updates the installed files.
The script may be run manually, from a login profile script, as a cron
job, or from an MS Windows Scheduled Task.
For more information see the project home page:
https://mailfud.org/geoip-legacy
This package will rarely be updated as the data changes weekly and the
database updater script geoipupdate will keep the data current.
Existing source package:
https://cygwin.com/packages/summary/geoipupdate-src.html
Existing cygport:
https://cygwin.com/cgit/cygwin-packages/geoipupdate/
[ITA] GeoIP, GeoIP-database, geoipupdate
-- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry patching configure.ac? In this update, the geoipupdate source and databases are no longer available, so the new upstream database source update script becomes a new database subpackage and script geoipupdate, and the old geoipupdate source, binary, and debuginfo packages should become obsolete. Is there anything special required to replace a source package and binaries with a binary subpackage? Below are links to existing source packages, build repos, scallywag runs, and updated package info. Geographic IP Lookup utilities, development, and runtime Existing source package: https://cygwin.com/packages/summary/GeoIP-src.html Updated cygport: https://cygwin.com/cgit/cygwin-packages/GeoIP/tree/GeoIP.cygport?h=playground Scallywag runs: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP Geographic IP Lookup utilities, development, and runtime GeoIP finds geographic and network locations of an IP address. For more information see the project home page: https://github.com/maxmind/geoip-api-c See below for details of changes: https://github.com/maxmind/geoip-api-c/blob/master/ChangeLog GeoIP-database Geographic IP Lookup (databases) Existing source package: https://cygwin.com/packages/summary/GeoIP-database-src.html Updated cygport: https://cygwin.com/cgit/cygwin-packages/GeoIP-database/tree/?h=playground Scallywag runs: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=GeoIP-database GeoIP-database Geographic IP Lookup (databases) GeoIP finds geographic and network locations of an IP address. These databases are extracts of free GeoLite2 data from Maxmind https://www.maxmind.com/ and are less accurate than the commercial databases. geoipupdate Geographic IP Lookup (database update utility) geoipupdate database updater script downloads the latest available data and updates the installed files. The script may be run manually, from a login profile script, as a cron job, or from an MS Windows Scheduled Task. For more information see the project home page: https://mailfud.org/geoip-legacy This package will rarely be updated as the data changes weekly and the database updater script geoipupdate will keep the data current. Existing source package: https://cygwin.com/packages/summary/geoipupdate-src.html Existing cygport: https://cygwin.com/cgit/cygwin-packages/geoipupdate/
Re: Change for the initial installation of Cygwin to set the default terminal terminal 256 color
The Cygwin native terminal emulator `mintty` is supported by Cygwin default `ncurses`/`terminfo` installs: $ TERM=mintty tput colors 256 On 2024-04-12 07:27, Thomas Wolff via Cygwin wrote: Am 12.04.2024 um 11:18 schrieb Lee via Cygwin: On Fri, Apr 12, 2024 at 4:05 AM J M wrote: Some examples that I view that can do Cygwin better by default: tput colors 8 echo $TERM xterm I made my mintty changes by point & click experimentation - if you want to make system-wide changes the place to do that is in /etc/minttyrc https://github.com/mintty/mintty/wiki/Tips Configuring mintty For its configuration, it reads configuration files in this order: /etc/minttyrc ... etc. $ grep -i term .minttyrc Term=xterm-256color $ tput colors 256 $ echo $TERM xterm-256color Note that mintty always supports all modes, including 256 colours and true-color (TERM=xterm-direct), regardless of the TERM setting or the $TERM environment value. That value is only used by some applications (like tput and apparently vim) as an indication which features to use. Thomas And if use vim, comparing with one Ubuntu terminal: I need to set "set mouse-=a" because the copy paste is difficult. The colors are very bright. The cursor does not look good when doing a search and moves over the yellow background text. What settings would I need to make it look like Ubuntu's vim? I'd suggest doing a 'man vim' to find out where all the possible configuration files are & then copy them to your cygwin machine. El jue., 11 abr. 2024 14:36, J M escribió: You can change in the initial install setup of Cygwin to set the default terminal to 256 color as Ubuntu does? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Use Microsoft YaHei UI as UI font for Chinese language
On 2024-04-11 06:42, Jon Turney via Cygwin wrote: On 03/04/2024 14:19, Yang Yu Lin via Cygwin wrote: For Chinese language, the app’s default UI font is Microsoft YaHei UI. Using MS Shell Dlg makes the UI become annoying. Here are my changes: diff --git a/res/zh_Hans/res.rc b/res/zh_Hans/res.rc index 9f67a5a..da9d6e8 100644 --- a/res/zh_Hans/res.rc +++ b/res/zh_Hans/res.rc @@ -8,7 +8,7 @@ LANGUAGE LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED IDD_SOURCE DIALOG 0, 0, SETUP_STANDARD_DIALOG_DIMS STYLE DS_MODALFRAME | DS_CENTER | WS_CHILD | WS_CAPTION | WS_SYSMENU CAPTION "Cygwin 安装程序 - 选择安装类型" -FONT 8, "MS Shell Dlg" +FONT 9, "Microsoft YaHei UI" Thanks very much for this patch! So, this isn't applicable as is, because the localized res.rc files are generated from a template res.rc file and the language .po file (using po2rc from Translate Toolkit [1][2]). See section starting after "rules for translation maintenance" in Makefile.am However, this seems like it would be straightforward to do via a post-processing step there. I'll take your word over the aesthetics of the font choice, but I do have a question about what versions of Windows we can assume that font is available on (in theory at least, one might be using a current setup executable to install Cygwin from the CTM on OSs back to Windows XP3) MS Yahei UI appeared in Win8; Yahei Reg/Bold in Win7. I wonder if we ought to be using "MS Shell Dlg 2" and/or DS_SHELLFONT, but the documentation about those is incomprehensible. They appear to be intended to be "localizable" font names implemented using font substitution on each Windows language version to MS Sans Serif (MS UI Gothic if jp) and Tahoma (2 was for W2K): https://learn.microsoft.com/en-us/windows/win32/intl/using-ms-shell-dlg-and-ms-shell-dlg-2 https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Intl/using-ms-shell-dlg-and-ms-shell-dlg-2.md If you have any future patches to setup, please send them to the cygwin-apps mailing list [1] https://github.com/translate/translate [2] (Although there may be some patches needed which have yet to make it upstream, so this might not work for you, yet) -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Win32 FILE_BASIC_INFORMATION.*Time.QuadPart - which value should be used if filesystem does not support it, so Cygwin /usr/bin/stat lists the value as '-'?
On 2024-04-09 15:14, Corinna Vinschen via Cygwin wrote: On Apr 5 04:26, Martin Wege via Cygwin wrote: On Fri, Apr 5, 2024 at 2:05 AM Martin Wege wrote: I have problems with debugging, so a quick help would be appreciated, as I cannot figure this out after several hours of digging. Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value must the CreationTime member of FILE_BASIC_INFORMATION have to cause /usr/bin/stat ti return "-"? 0, -1, or something else? In a related matter: The Win32 FILE_BASIC_INFORMATION structure defines four time values: LARGE_INTEGER CreationTime; LARGE_INTEGER LastAccessTime; LARGE_INTEGER LastWriteTime; LARGE_INTEGER ChangeTime; How can a filesystem indicate if it does not support a particular timestamp, such as ChangeTime? Should ChangeTime.QuadPart then be -1, -2 or 0, or another value? I'm not aware of a filesystem not supporting ChangeTime, that is, st_ctime. Usually only CreationTime (st_birthtime) is missing. R/O media like CD/DVD-R or FS w/o write support? I think setting the timestamp to 0 works for indicating that this kind of timestamp is not supported. Cygwin is handling Windows timestamps this way, but I can't find this in documentation ATM. See upthread?: Caller or application can set 0 to mean keep/return current value, caller or driver can set -1 to mean don't update/return current value: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_file_basic_information#remarks But the FS driver can also just fill the CreationTime field with the same value as LastWriteTime or ChangeTime. MSFT NFS does 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: /proc//{cwd, root} links to for cygrunsrv, daemons, and shells
On 2024-04-09 07:08, Corinna Vinschen wrote:
On Apr 7 13:34, Brian Inglis wrote:
ISTM anomalous that for cygrunsrv, daemons, cron processes, and shells
/proc//{cwd,root} have bad symlinks to "", normally a process
or exe status:
/proc/732/exe -> /usr/bin/cygrunsrv
/proc/732/root ->
/proc/732/cwd ->
| /proc/733/exe -> /usr/sbin/cygserver
->/proc/733/root ->
/proc/733/cwd ->
/proc/740/exe -> /usr/bin/cygrunsrv
/proc/740/root ->
/proc/740/cwd ->
| /proc/741/exe -> /usr/sbin/syslog-ng
->/proc/741/root ->
/proc/741/cwd ->
/proc/748/exe -> /usr/bin/cygrunsrv
/proc/748/root ->
/proc/748/cwd ->
| /proc/749/exe -> /usr/sbin/cron
->/proc/749/root ->
/proc/749/cwd ->
| /proc/2080/exe -> /usr/sbin/cron
->/proc/2080/root ->
/proc/2080/cwd ->
| /proc/2082/exe -> /usr/bin/bash
->/proc/2082/root ->
/proc/2082/cwd ->
Should we consider changing that to root "/", or nothing, null, or something
meaningful?
That's typically a permission problem. On Linux you get something like
ls: cannot read symbolic link '/proc/1/cwd': Permission denied
Thanks Corinna,
That now makes sense, as Cygwin ps -a and btop showed the processes, although
procps and top did not, and other info is visible, I never thought about
permissions as there were links, but I see from elevated admin sh:
/proc/732/exe -> /usr/bin/cygrunsrv
/proc/732/root -> /
/proc/732/cwd -> /proc/cygdrive/c/WINDOWS/system32
| /proc/733/exe -> /usr/sbin/cygserver
->/proc/733/root -> /
/proc/733/cwd -> /proc/cygdrive/WINDOWS/system32
/proc/740/exe -> /usr/bin/cygrunsrv
/proc/740/root -> /
/proc/740/cwd -> /proc/cygdrive/WINDOWS/system32
| /proc/741/exe -> /usr/sbin/syslog-ng
->/proc/741/root -> /
/proc/741/cwd -> /proc/cygdrive/WINDOWS/system32
/proc/748/exe -> /usr/bin/cygrunsrv
/proc/748/root -> /
/proc/748/cwd -> /proc/cygdrive/WINDOWS/system32
| /proc/749/exe -> /usr/sbin/cron
->/proc/749/root -> /
/proc/749/cwd -> /var/cron
and from normal mintty bash:
$ stat -L -c%a\ %A\ %n /proc/732/*
444 -r--r--r-- /proc/732/cmdline
444 -r--r--r-- /proc/732/ctty
stat: cannot stat '/proc/732/cwd': No such file or directory
444 -r--r--r-- /proc/732/environ
755 -rwxr-xr-x /proc/732/exe
444 -r--r--r-- /proc/732/exename
555 dr-xr-xr-x /proc/732/fd
444 -r--r--r-- /proc/732/gid
444 -r--r--r-- /proc/732/maps
444 -r--r--r-- /proc/732/mountinfo
444 -r--r--r-- /proc/732/mounts
444 -r--r--r-- /proc/732/pgid
444 -r--r--r-- /proc/732/ppid
stat: cannot stat '/proc/732/root': No such file or directory
444 -r--r--r-- /proc/732/sid
444 -r--r--r-- /proc/732/stat
444 -r--r--r-- /proc/732/statm
444 -r--r--r-- /proc/732/status
444 -r--r--r-- /proc/732/uid
444 -r--r--r-- /proc/732/winexename
444 -r--r--r-- /proc/732/winpid
$ more /proc/732/* > /dev/null
more: cannot open /proc/732/cwd: No such file or directory
more: cannot open /proc/732/maps: Permission denied
more: cannot open /proc/732/root: No such file or directory
more: cannot open /proc/732/stat: Permission denied
more: cannot open /proc/732/statm: Permission denied
so I think perms on these should be 440 or 550 not 444 or 555, but that may
involve a lot of work to decide that for each entry?
But on Cygwin the content of those links require to open the processes'
signal pipe and send/receive a message containing the information. I
didn't look into the code for a while but it seems we don't check why we
couldn't connect to a process to fetch the info. IIRC the current
fhandler_process framework doesn't have a way to communicate that
info.
If you want to change that, feel free!
I will take a look sometime but no promises of any patch(es) ;^>
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
/proc//{cwd, root} links to for cygrunsrv, daemons, and shells
ISTM anomalous that for cygrunsrv, daemons, cron processes, and shells
/proc//{cwd,root} have bad symlinks to "", normally a process or
exe status:
/proc/732/exe -> /usr/bin/cygrunsrv
/proc/732/root ->
/proc/732/cwd ->
| /proc/733/exe -> /usr/sbin/cygserver
->/proc/733/root ->
/proc/733/cwd ->
/proc/740/exe -> /usr/bin/cygrunsrv
/proc/740/root ->
/proc/740/cwd ->
| /proc/741/exe -> /usr/sbin/syslog-ng
->/proc/741/root ->
/proc/741/cwd ->
/proc/748/exe -> /usr/bin/cygrunsrv
/proc/748/root ->
/proc/748/cwd ->
| /proc/749/exe -> /usr/sbin/cron
->/proc/749/root ->
/proc/749/cwd ->
| /proc/2080/exe -> /usr/sbin/cron
->/proc/2080/root ->
/proc/2080/cwd ->
| /proc/2082/exe -> /usr/bin/bash
->/proc/2082/root ->
/proc/2082/cwd ->
Should we consider changing that to root "/", or nothing, null, or something
meaningful?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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: Cygwin a bit slow
On 2024-04-05 09:21, J M via Cygwin wrote: I added, sed and grex x60 to x80, no software running and no antivirus. El vie., 5 abr. 2024 17:18, J M escribió: I'm seeing that Cygwin is a bit slow, directly and after comparing to simple ubuntu virtual machines by example. Specifically: - Copy and paste texts in vim, I see clearly the slow in paste. - Using sed and/or grep that count approx. between 6x and 8x respect to virtual machine simple ubuntu. - In general multiple bash commands are slower. Can you analyze this? I'm use the last updated Windows 11 and a fresh Cygwin. Any chance Cygwin may be running under Hyper-V due to possibly unrequested security changes, such as enabling Device Security/Core Isolation/Memory Integrity, because of enabling logging/reporting back to MS, or checking signature on each execution of each executable, or other "security" features (by default bypassed by buggy/unsafe MS products, which are the ones that need it)? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin /usr/bin/stat returns "Birth: -", which value in FILE_BASIC_INFORMATION.CreationTime causes that?
On 2024-04-04 19:08, Martin Wege via Cygwin wrote: On Fri, Apr 5, 2024 at 2:55 AM Brian Inglis via Cygwin wrote: On 2024-04-04 18:05, Martin Wege via Cygwin wrote: I have problems with debugging, so a quick help would be appreciated, as I cannot figure this out after several hours of digging. Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value must the CreationTime member of FILE_BASIC_INFORMATION have to cause /usr/bin/stat ti return "-"? 0, -1, or something else? https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/stat.c#n1618 => tv_nsec < 0 https://cygwin.com/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler/disk_file.cc#l414 https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/times.cc#l283 Thank you But how can tv_nsec become negative (tv_nsec < 0)? That can only happen if BasicInformation.CreationTime.QuadPart is negative, right? Caller or application can set 0 to mean keep/return current value, caller or driver can set -1 to mean don't update/return current value: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_file_basic_information#remarks -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin /usr/bin/stat returns "Birth: -", which value in FILE_BASIC_INFORMATION.CreationTime causes that?
On 2024-04-04 18:05, Martin Wege via Cygwin wrote: I have problems with debugging, so a quick help would be appreciated, as I cannot figure this out after several hours of digging. Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value must the CreationTime member of FILE_BASIC_INFORMATION have to cause /usr/bin/stat ti return "-"? 0, -1, or something else? https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/stat.c#n1618 => tv_nsec < 0 https://cygwin.com/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler/disk_file.cc#l414 https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/times.cc#l283 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin file prefetch, block sizes?
On 2024-04-03 00:44, Cedric Blancher via Cygwin wrote: On Wed, 3 Apr 2024 at 03:10, Mark Geisert via Cygwin wrote: On 4/2/2024 3:35 PM, Martin Wege via Cygwin wrote: On Tue, Apr 2, 2024 at 3:17 PM Corinna Vinschen via Cygwin wrote: On Apr 2 02:04, Martin Wege via Cygwin wrote: Is there any document which describes how Cygwin and Win32 file prefetch and readahead work, and which sizes are used (e.g. always read one full page even if only 16 bytes are requested?)? I'm not aware of any docs, but again, keep in mind that Cygwin is a userspace DLL. We basically do what Windows does for low-level file access. Quick /usr/bin/stat /etc/profile returns "IO Block: 65536". Does that mean the file's block size is really 64k? Is this info per filesystem, or hardcoded in Cygwin? Hardcoded in Cygwin since 2017, based on a discussion in terms of file access performance, especially when using stdio.h functions: https://cygwin.com/cgit/newlib-cygwin/commit/?id=7bef7db5ccd9c OUCH. While I can understand the motivation, FAT32 on multi-GB-devices having 64k block size, and Win32 API on Win95/98/ME/Win7 being Those 32 bit systems stopped being of interest long ago and 32 bit Windows and Win7 are no longer supported. optimized to that insane block size, it is absolutely WRONG with today's NTFS and even more so with ReFS. This only works if you stream files, but as soon as you are doing random read/writes the performance is terrible due to cache thrashing. That could explain the many complaints about Cygwin's IO performance. Most Cygwin random read/writes are likely for directories. Any random file I/O is down to the application's needs. No comment. So, what can be done? I'm not a benchmarking guru, so I'd like to propose to add a tunable called EXPERIMENTAL_PREFERRED_IO_BLKSIZE to the CYGWIN env variable (marked as "experimental"), so the benchmarking guys can do performance testing without recompiling everything, get perf results for Cygwin 3.6, and decide what to do for Cygwin 3.7. That kind of experiment is what folks who can build their own cygwin1.dll might do. I doubt we'd want to make a run-time global disk I/O strategy changer available like this, even temporarily. Realistically that would mean that Cygwin will forever be stuck with an insane IO block size. Building Cygwin.dll requires specialised knowledge and TIME, and no manager will waste the time of a performance engineer to produce custom binaries. Cygwin 3.6 is right now in development, so it would be better to add such a knob, so performance engineers can just grab those binaries and do benchmarking with them. Benefit for majority of users to have volunteers do that, rather than address Cygwin issues and keep up to date with Windows releases? If they can pay for benchmarking and performance engineers, they can pay to make their own changes, and do their own builds. No one is saying they have issues and why, and want to bench Cygwin I/O and share their results with us. BTW: A block size of 64k is CLEARLY harming performance. Have a look at https://www.zabkat.com/blog/buffered-disk-access.htm the sweet spot is somewhere between 16k and 32k, for SMB even below that. 64k is clearly on the backside of the curve, and actively harming performance, except for "linear reads". A decade ago in 2013! I have older papers recommending 4KB and 8KB blocks and pages, and other older papers from that same period recommending 40KB or track sized I/O. Remember Cygwin does its own directory reads so 64KB is probably about right for NTFS entries into dirent. Unless someone has done benchmarking to prove that some other number would be better in future, making it smaller probably does not make any sense. What could make sense is enhancing Cygwin's posix_fadvise() to support POSIX_FADV_RANDOM getting mapped to Windows' FILE_RANDOM_ACCESS flag. Something like this is currently done for POSIX_FADV_SEQUENTIAL -> FILE_SEQUENTIAL_ONLY. These are per-filedescriptor adjustments and due to Windows limitations would apply to a whole file rather than having the POSIX behavior of being settable for a byte range within a file. Nope. Because we are talking about a sensible default for all applications, and a block size of 64k is HARMFUL, except on fat32 where the filesystem block size is already 64k for multi gigabyte disks. Who uses FAT32 for large drives except maybe flash, not even then if they're smart? Even in the small, slow old days, the equivalent of readfile(2), and mmap(2) were better choices. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: htt
OSS-Sec: X.Org Security Advisory
Issues in X.Org X server prior to 21.1.12 etc. https://seclists.org/oss-sec/2024/q2/22 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: xargs completely broken under cygwin 3.6.0-0.108.gb7f5a33200a9
On 2024-04-01 21:36, Bruce Jerrick via Cygwin wrote:
'xargs' (part of 'findutils') is completely broken if
3.6.0-0.108.gb7f5a33200a9 (test version) is installed:
^ Cygwin
$ xargs
xargs: Unexpected suffix cmdline on cmdline
$ xargs --version
xargs: Unexpected suffix cmdline on cmdline
$ echo narf | xargs echo
xargs: Unexpected suffix cmdline on cmdline
'xargs' is from the current x86_64 findutils-4.9.0-1 .
All other packages are up to date per setup.ini dated
2024-04-01 21:32:37 GMT.
I first discovered this under Windoze 11 Insider Preview
(with no other Cygwin test versions).
On a Windoze 10 machine, it was OK with cygwin 3.5.1-1,
appeared when I installed 3.6.0-0.108.gb7f5a33200a9,
then went away when I reverted to 3.5.1-1 .
(All machines are VMware VM's.)
I have just started looking at the source, and the error
is coming from this snippet from 'safe_atoi()' in
lib/safe-atoi.c :
^ findutils 4.9.0
safe_atoi (const char *s, enum quoting_style style)
{
...
lval = strtol (s, , 10);
...
else if (*end)
{
die (EXIT_FAILURE, errno, _("Unexpected suffix %s on %s"),
quotearg_n_style (0, style, end),
quotearg_n_style (1, style, s));
}
...
That function safe_atoi() appears only to be called by xargs from
remember_non_cloexec_fds() -> get_max_fd() -> get_proc_max_fd(), all in
lib/fdleak.c and appears to be trying to convert the text cmdline, which should
not happen because it is trying to open, read, and convert directory entries
from /proc/self/fd.
Could you please try running:
$ xargs -t --show-limits < /dev/null
Your environment variables take up 9285 bytes
POSIX upper limit on argument length (this system): 20667
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 11382
Size of command buffer we are actually using: 20667
Maximum parallelism (--max-procs must be no greater): 2147483647
echo
and it would be useful if you could run a failing command under strace e.g.
$ strace -o xargs.strace xargs -t --show-limits < /dev/null
or similar and attach as text to your reply.
There could be something funny going on with recent changes to Cygwin directory
lookup affecting proc virtual file system lookups e.g.
Cygwin: implement dirent.d_reclen
https://cygwin.com/cgit/newlib-cygwin/commit/?h=topic/3.6=7e40e0169a75ebdf3f3861dab47abdfeb0ad9c58
and subsequent changes around dirents.
Could someone please take a look at those recent changes, testing access to proc
file system entries, perhaps also with xargs, in case access to virtual files
have issues?
From 'man 3 strtol":
"If the subject string is empty (or not in acceptable form),
no conversion is performed and the value of s is stored
in ptr [i.e., 'end'] ..."
Which is apparently what is happening here.
I have yet to discover where "cmdline" is coming from (perhaps
/proc/%d/cmdline), let alone what it looks like.
Further progress by me will depend on what success I have in
building 'findutils' from source :) .
For more info, install cygwin-doc, and run:
$ man 5 proc
Contents of /proc/.../cmdline is an argv array:
$ cat -A /proc/self/cmdline; echo
cat^@-A^@/proc/self/cmdline^@
There could also be something funny going on with recent changes to Cygwin
process startup e.g.
Cygwin: redefine CW_CMDLINE to CW_CMDLINE_ALLOC
https://cygwin.com/cgit/newlib-cygwin/commit/?h=topic/3.6=732afede935832beab181ae421c1366df2ae6af5
Could someone please take a look at those recent changes, testing with xargs, in
case base assumptions of argv[] command line arguments and environ, envp[]
environment variables address locations, terminators, atexit routines, could be
broken?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: xz upstream backdoor compromise (was: Cygwin: Linux xz issue)
On 2024-03-29 16:43, Ron Murray via Cygwin wrote: There is a serious security issue with xz (and liblzma) versions 5.6.0-1 and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't see a reference to this: sorry if you're already aware of this issue. References: https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094 https://access.redhat.com/security/cve/CVE-2024-3094 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-backdoor-in-xz-utils/ https://seclists.org/oss-sec/2024/q1/268 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: When displaying Chinese help information in Cygwin setup, the program does not respond. The code enters a dead loop.
On 2024-03-28 09:26, 赵伟 via Cygwin wrote:
When displaying Chinese help information, the program does not respond.
The code enters a dead loop in file
"libgetopt++/include/getopt++/DefaultFormatter.h"，
because some Chinese help information does not contain spaces.
diff --git a/libgetopt++/include/getopt++/DefaultFormatter.h
b/libgetopt++/include/getopt++/DefaultFormatter.h
index ee2397f5..19ac67e1 100644
--- a/libgetopt++/include/getopt++/DefaultFormatter.h
+++ b/libgetopt++/include/getopt++/DefaultFormatter.h
@@ -64,6 +64,7 @@ class DefaultFormatter {
{
// TODO: consider using a line breaking strategy here.
int pos = helpmsg.substr(0,h_len).find_last_of(" ");
+ if (pos <= 0) break;
theStream << helpmsg.substr(0,pos)
<< std::endl << std::string (o_len, ' ');
helpmsg.erase (0,pos+1);
It seems that the best approach for Chinese translations would be to:
- add spaces at sentence or word breaks in translations before 35 or 45 bytes,
if that is the length unit, worth of characters are output in each column; or
- add a language dependent line breaking strategy, to honour characters not to
be placed at the beginning or ends of lines or split; or
- split between characters, as with long strings in other languages.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH setup] Fix Chinese Help Message fall in dead loop .
On 2024-03-28 19:40, 赵伟 via Cygwin-apps wrote:
---
libgetopt++/include/getopt++/DefaultFormatter.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libgetopt++/include/getopt++/DefaultFormatter.h
b/libgetopt++/include/getopt++/DefaultFormatter.h
index ee2397f5..43c253a5 100644
--- a/libgetopt++/include/getopt++/DefaultFormatter.h
+++ b/libgetopt++/include/getopt++/DefaultFormatter.h
@@ -64,6 +64,7 @@ class DefaultFormatter {
{
// TODO: consider using a line breaking strategy here.
int pos = helpmsg.substr(0,h_len).find_last_of(" ");
+ if(!pos)break; /*In Chinese Helpmsg,may has no space,so pos ==0,and
code will fall in dead loop here*/
theStream << helpmsg.substr(0,pos)
<< std::endl << std::string (o_len, ' ');
helpmsg.erase (0,pos+1);
It seems that the best approach for Chinese translations would be to:
- add spaces at sentence or word breaks in translations before 35 or 45 bytes,
if that is the length unit, worth of characters are output in each column; or
- add a language dependent line breaking strategy, to honour characters not to
be placed at the beginning or ends of lines or split; or
- split between characters, as with long strings in other languages.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 2024-03-28 11:49, Jon Turney via Cygwin-apps wrote:
On 27/03/2024 21:18, Brian Inglis via Cygwin-apps wrote:
On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:
On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
On 24/03/2024 15:07, Jon Turney wrote:
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
[...]
Are they supposed to migrate to some alternate bindings maybe available from
a separate repo? Or are they just out of luck?
SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.
Nice :S
Feel free to purge as appropriate, or tell me what to add to cygport, hints,
etc!
So, the long list of source versions will hopefully be reduced in the
fullness of time...
Could I just add to nghttp2.cygport that nghttp2 obsoletes
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2
vx.x.x around?
You could, but that's probably not the correct thing to do unless you really,
really want to forcibly uninstall those packages for anyone who has installed
them, which seems like unnecessary breakage.
I don't think you have to do anything. There's nothing "wrong" here.
If it really offends your sense of aesthetics, I suggest you just expire some
subset of the old versions using the vault command [1].
[1] https://cygwin.com/package-upload.html#deleting
Great idea!
Current setup packages are:
python3-nghttp2 1.43.0-1 x86_64
python36-nghttp2 1.46.0-1 x86_64
python37-nghttp2 1.46.0-1 x86_64
python38-nghttp2 1.51.0-1 x86_64
python39-nghttp2 1.51.0-1 x86_64
and 37 obsoletes 36 obsoletes 3, so from src:
Version Package Size DateFiles Status
1.31.0-1 (source) 1512 KiB 2018-03-16 01:07 [list of files] stable
1.37.0-1 (source) 1593 KiB 2019-03-27 03:17 [list of files] stable
1.43.0-1 (source) 3885 KiB 2021-05-30 06:33 [list of files] stable
1.44.0-1 (source) 3884 KiB 2021-07-19 11:32 [list of files] stable
1.45.1-1 (source) 3929 KiB 2021-09-26 12:08 [list of files] stable
1.46.0-1 (source) 3936 KiB 2021-10-24 03:17 [list of files] stable
1.49.0-1 (source) 4021 KiB 2022-08-28 01:08 [list of files] stable
1.50.0-1 (source) 4019 KiB 2022-09-25 19:43 [list of files] stable
1.51.0-1 (source) 4025 KiB 2022-11-13 20:42 [list of files] stable
1.58.0-1 (source) 1515 KiB 2023-10-29 17:13 [list of files] stable
1.59.0-1 (source) 1516 KiB 2024-01-21 19:31 [list of files] stable
1.60.0-1 (source) 1554 KiB 2024-03-03 17:16 [list of files] stable
I should be able to vault 1.31-1.45 and 1.49-1.50, or should I also add 1.46?
Could I also selectively upload -*.tar.xz for old python package versions?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: [tz] Ubuntu drops old-style links - tzdata split test package
On 2024-03-28 04:13, Corinna Vinschen via Cygwin-apps wrote: On Mar 28 02:25, Brian Inglis via Cygwin-apps wrote: I have released and announced a test package of tzdata 2024a-2 split into three install packages: base tzdata, optional tzdata-right, and redundant tzdata-posix, each containing all the legacy zones so that tzset continues to work as before. I could not reduce the base installed zones by many, because most were used by tzset, but I did drop a couple of large zone source files, produced by the build, that were previously included to allow users to see the source zones, rules, and links in effect, saving ~1MB, and dropping the overall default base installed file sizes by ~80% to ~20% of current, and download tar size by ~60% to ~40%; for all zones aggregate total installed file sizes are dropped by ~35% to ~65%, and download tar sizes by ~30% to ~70% of current: install tar tzdata 721KB 172KB base 984KB 78KB right 669KB 74KB posix 1367KB 444KB source 3667KB 452KB current Please check out the announcement, cygwin list echo, source and install package summary web pages, cygport changes, setup entries, scallywag builds, and let me know if there is anything you see that could benefit from improvement. Fedora Rawhide is not following this scheme. For F40 and F41 it still prepares single tzdata packages. FWIW, OpenSuSE also only comes with a single timezone package in Tumbleweed. Comparing the Cygwin and the Fedora package, the only differences are: Cygwin comes with two files not in the Fedora package: /usr/share/zoneinfo/rearguard.zi Source tzdata zones, rules, links, - driven by tzdata make symbol settings, - in legacy tzdata format supported by newlib-cygwin libc, - generated as base zic input source to provide all the legacy zones used by tzset, and - allows users to view the tzdata rules in effect for their zone(s) of interest; - dropped in the test package, - along with tzdata.zi, which is the abbreviated generated source file used by zic to build the zoneinfo subtrees, - driven also by zic parameters for each subtree, almost identical to Fedora: https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec - except they still use the deprecated obsolete yearistype shell script with zic, supporting deprecated obsolete US presidential and odd/even year rules. Once we know that the libc code is updated to support the new zic output data ranges, we could transition to main or vanguard source formats and slim output formats, as long as the required tzset zone files are still generated in those formats. This is the same as provided in RHEL, see notes on tzdata-2018e in: https://access.redhat.com/articles/1187353 and Fedora https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec /usr/share/zoneinfo/zonenow.tab Compare the RH notes, Fedora tzdata.spec embedded changelog, cygport git log, and cygwin-announce upstream release notes, for similar information. New minimal tzdata zone selection which builds *only* the minimal zones required to provide current time around the world, but may require selection of a different zone; supported by make and in /bin/tzselect by undocumented -t zonetabtype option. Fedora comes with two files not in the Cygwin package: /usr/share/zoneinfo/leap-seconds.list IERS/NIST upstream NTP leap-seconds.list PD distribution file: we provide only the tzdata format leapseconds file in /usr/share/zoneinfo/, generated from the NTP list, instead; that way we do not need to specify another licence, which appears not to be stated in: https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec /usr/share/zoneinfo/posixrules Deprecated obsolete legacy rules: see tzdata-2020b notes discussing patch to provide this in: https://access.redhat.com/articles/1187353 and 2020d-3 notes in: https://src.fedoraproject.org/rpms/tzdata/blob/rawhide/f/tzdata.spec That's all. And given that space is not one of the major limiting factors anymore... cyg$ du -sh /usr/share/zoneinfo 6.6M/usr/share/zoneinfo fed$ du -sh /usr/share/zoneinfo 4.6M /usr/share/zoneinfo ...I do wonder a bit if this split is really necessary after all. It cuts the base install (--apparent) size by ~3MB to 721KB, time and load for this by a factor of 5, for mirrors, CI, and other repetitive container and packaged build server installs like ansible, docker, scallywag, etc. Few users are likely to use any of the right or redundant posix subtrees, unless they have astrophysics or time/frequency physics interests. Astronomers and astrologers, CLDR, ICU, and Cygwin Windows tzmap are better served by providing all the legacy zones. FYI: The primary maintainer of tzcode/tzdata is an Ubuntu user, and keen to drop as much of the legacy and what he considers as questionable history as possible, despite a project data fork
Re: [tz] Ubuntu drops old-style links - tzdata split test package
On 2024-03-23 15:11, Corinna Vinschen via Cygwin-apps wrote:
On Mar 23 10:38, Brian Inglis via Cygwin-apps wrote:
It looks to me that tzset.c prioritizes the Windows label over the country,
and it may be a better match prioritizing the country over the label, if the
country is not 001/"", nor ZZ, which are the generic entries.
The Windows timezone is the relevant setting in the first place becasue
that's what indicvates the actual local time *as the user chose*.
The territory should only be a secondary hint to choose the right
POSIX entry.
For instance, I know people always using UTC, independently of their
territory setting. If the territory rules, this user choice would be
broken in Cygwin.
It also is not clear what tzset should do when tzmap has a list of zones to
choose from, for example:
{ L"Mountain Standard Time", L"CA", L"America/Edmonton
America/Cambridge_Bay America/Inuvik" },
{ L"Mountain Standard Time", L"US", L"America/Denver America/Boise" },
{ L"US Mountain Standard Time", L"CA", L"America/Creston
America/Dawson_Creek America/Fort_Nelson" },
it currently just prints the first, but perhaps it should print all relevant
entries and the caller should handle the alternatives?
tzset is called from the shell default profile. It has to use exactly
one, valid entry, so time works as desired without forcing interactivity.
If the user doesn't like it, the user can always override tzset's choice
in her own profile.
I have released and announced a test package of tzdata 2024a-2 split into three
install packages: base tzdata, optional tzdata-right, and redundant
tzdata-posix, each containing all the legacy zones so that tzset continues to
work as before.
I could not reduce the base installed zones by many, because most were used by
tzset, but I did drop a couple of large zone source files, produced by the
build, that were previously included to allow users to see the source zones,
rules, and links in effect, saving ~1MB, and dropping the overall default base
installed file sizes by ~80% to ~20% of current, and download tar size by ~60%
to ~40%; for all zones aggregate total installed file sizes are dropped by ~35%
to ~65%, and download tar sizes by ~30% to ~70% of current:
install tar tzdata
721KB 172KB base
984KB 78KB right
669KB 74KB posix
1367KB 444KB source
3667KB 452KB current
Please check out the announcement, cygwin list echo, source and install package
summary web pages, cygport changes, setup entries, scallywag builds, and let me
know if there is anything you see that could benefit from improvement.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: Test: tzdata, tzdata-right, tzdata-posix 2024a-2 (TEST)
Please provide feedback on these changes in this test release if splitting the tzdata packages as described may have a negative impact on your system. On 2024-03-28 01:39, Cygwin tzcode/tzdata Maintainer wrote: The following test packages have been uploaded to the Cygwin distribution: * tzdata2024a-2 * tzdata-right 2024a-2 * tzdata-posix 2024a-2 This Cygwin test release splits out the likely rarely used "right" and "posix" subtrees from mandatory base /usr/share/zoneinfo into their own optional packages tzdata-right and tzdata-posix. Tests checking for missing or invalid representative zones in all parts of the base, posix, and right subtrees has been added as part of the package definition script. Please test this base package and report any issues, and let us know if you need to install and use the zones in the "right" or "posix" subtrees in the optional tzdata-right and tzdata-posix packages, and whether this change causes any issues for you. If there are no reports of issues, all future tzdata updates will be split into three packages, and only the base tzdata package installed by default on all systems. The space occupied by installed files, and downloaded from mirrors, is shown below for each package, plus the current package with all zones. install tar tzdata 721KB 172KB base 984KB 78KB right 669KB 74KB posix 1367KB 444KB source 3667KB 452KB current The Time Zone Database (often called tz, tzdb, or zoneinfo) contains data that represents the history of local time for many locations around the world, and supports conversion of UTC time to local time at those locations to allow display of those local times. It is updated periodically to reflect changes made by political bodies to summer daylight saving time rules, UTC offsets, and time zone boundaries. Three data packages are available: base 'tzdata' is always installed; optional 'tzdata-right' provides TAI-10s time in the 'right' subtree; and optional 'tzdata-posix' provides the same zones and times as base data in the 'posix' subtree, as an explicit distinction from 'right'. The tzcode package provides the tzselect, zdump, and zic utilities. For more information, see the project home page: https://www.iana.org/time-zones -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Request to add Finnish (fi_FI) as a language for this project on Weblate
On 2024-03-27 04:15, Ricky Tigg via Cygwin wrote: Good morning. What is the constantly renewed disappointment of having to note that even today there are projects whose sites are poorly constructed and omit essential content. As with such a site, invariably we can see that the same error keeps being repeated; Make it complicated for the sake of making it complicated. See for yourself what this resulted in at https://cygwin.com/: nothing about localization, and therefore nothing, nor about the localization contribution of the application installer setup-x86_64.exe. nor about the existence of the localization platform that this project has chosen – Weblate. So in this context, it is of course futile to carry out a search engine search against the keywords "cygwin" and "localization" in the hope of seeing the said platform cited. Finally, the very choice of this platform easily turns out to have been a mistake; However, it was hardly the localization platforms including a communication channel to contact the project maintainer that were missing when this choice was made. Despite this, someone from this project found a way to choose one whose said service was lacking. See how this leads to wasting the time of any new person interested in this contribution. How do you usually go about satisfying a request as trivial as this? Sincerely. Cygwin is an all volunteer project: are you volunteering to provide Finnish translations for our infrastructure and packages? Two critical packages that would welcome Finnish localizations are Cygwin Setup setup-x86_64 and Terminal mintty: https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=res/en/res.rc https://github.com/mintty/mintty/blob/master/lang/messages.pot -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:
On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
On 24/03/2024 15:07, Jon Turney wrote:
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
[...]
Not sure why my source package nghttp2 shows python install packages, when
they were dropped after 1.43 IIRC: build deps no longer include python/-devel?
If you haven't taken any specific action to retire the python-3x-nghttp2
packages, the existing ones will continue to be available indefinitely.
Firstly, it seems there's a question here about what are upstream's plans for
the users of the python bindings for this library.
Are they supposed to migrate to some alternate bindings maybe available from a
separate repo? Or are they just out of luck?
SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.
And why does that nghttp2 source package show a dozen archived source
versions, when its installed packages have only three?
The simple answer to that is we retain the source package for all available
install packages. This seems essential for an open-source project.
Now, as to why there are so many installable packages, this is the intersection
of a couple of unfortunate issues.
1. 'python3-nghttp2' is an "old-style" obsoletion package, where the package
exists, but is of category _obsolete, and requires the replacement package.
These are terrible, because we can't remove the obsolete package because that's
what records the fact of obsoletion.
I actually have some code for calm to internally convert that to a "new-style"
obsoletion, where the replacement package itself records the obsoletion (i.e.
python36-nghttp2 obsoletes: python3-nghttp2), which it continues to remember
about even after the package which contains that obsoleting is expired.
Once that's done, all those "old-style" obsoletion packages lingering in our
package repository can be removed (along with their corresponding source).
But I still need to do some testing before that can be deployed.
(However, all that's probably not what's actually wanted with python packages:
it's preferable to have python3-foo be a virtual package which pulls in
python3x-foo, where python3x is the current python, so that scripted installs
can be written which ask for python3 and python3-foo and continue to work while
x changes...)
2. We haven't purged old python versions for a long time, so e.g the python36
binding packages are still lingering.
As you can see, I'm just now getting around to looking at expiring python36,
which eventually should lead to python36-nghttp2 being expired (insert some
observations about how it doesn't have to be me doing these things here)...
Feel free to purge as appropriate, or tell me what to add to cygport, hints,
etc!
So, the long list of source versions will hopefully be reduced in the fullness
of time...
Could I just add to nghttp2.cygport that nghttp2 obsoletes
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2 vx.x.x
around?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
Re: ntfs-3g/ntfssecaudit build failed with fatal error: linux/fd.h: No such file or directory
On 2024-03-24 12:59, Matthias--- via Cygwin wrote: I downloaded ntfs-3g_ntfsprogs-2022.10.3.tgz from tuxera, extract it and run, in my cygwin 3.5 environment: ./configure make ntfsprogs I got a "fatal error: linux/fd.h: No such file or directory". All ntfsprogs are build in ~/ntfsprogs but not ntfsrecover, ntfssecaudit and ntfsusermap. So do you have any hint where I can find this "linux/fd.h" ? On Linux! Check your config and make logs for questionable defaults or automatic selections. You may want to first try just `make`, to ensure that all subdirectory configs are done properly, as those are often run by the top level make, using the cached results from configure. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
