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