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

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

[Brian Inglis]

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 ?

[Bruno Haible]

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

Thanks!

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

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

I regularly build all my packages on 32-bit and 64-bit mingw. Also, I know that
GNU Emacs wants binaries that work on Windows XP, and that means 32-bit binaries.

> Steam estimated 32 bit games PCs ~ 0.25% in 2021, and dropped support in February.

Games are a particular niche of the PC market, isn't it? Hardware that consumes
lots of power and is loud, reflective displays, mostly proprietary software?

Bruno

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

[Jon Turney]

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!


> [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...)

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

[Brian Inglis]

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-reply@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.16241297892116907567@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

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

[Jon Turney]

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+AlfA@public.gmane.org
> To: Brian Inglis ...
> Reply-To: cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org
> Subject: calm: cygwin package report for Brian Inglis
> X-Calm-Report: 1
> Message-Id: 
> <171738805632.3596610.16241297892116907567-VPjUDf68pYP0lzK1ysf9sD64mgHaRSMb@public.gmane.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?

No, that's just me being distracted and forgetting to restart the thing 
so it re-reads the list.

Sorry about that.  Hopefully working now.

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

[Brian Inglis]

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+AlfA@public.gmane.org
>> To: Brian Inglis ...
>> Reply-To: cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org
>> Subject: calm: cygwin package report for Brian Inglis
>> X-Calm-Report: 1
>> Message-Id: 
>> <171738805632.3596610.16241297892116907567-VPjUDf68pYP0lzK1ysf9sD64mgHaRSMb@public.gmane.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?
> 
> 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 ?

[Bruno Haible]

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

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

[Brian Inglis]

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 ?

[Jon Turney]

On 04/06/2024 00:14, Brian Inglis via Cygwin-apps wrote:
> 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,
>>>
[...]
> 
> No previous debuginfo packages exist - are these not useful with cross 
> builds?

I suspect that maybe the previous package is so old we didn't have 
automatic debuginfo generation when it was built...