From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by sourceware.org (Postfix) with ESMTPS id 0081739502E8 for ; Mon, 3 Jun 2024 05:37:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0081739502E8 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSW.ab.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=SystematicSW.ab.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0081739502E8 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=216.40.44.17 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717393065; cv=none; b=m/ZvrWOnWMhZI92ZNodR1bCPeJBox01kwFwNmtEfcIohsRG4Y3D746KnTCUHSppQOsCMszOw/gX73ONLp4QDL8vT7ceDJCSrETOuqygoX0IsPO9W4wwlC7jPlEJkyDr+TR6TH8AXcbQA508hp2yiHaX4nej2SMtxPYIkCToCb3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717393065; c=relaxed/simple; bh=P4eSrq4qhVxWxN+m6TrBZj7j7JNMO+gNWkJ1io2lhDo=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=s6aOuf0fJuLTvcqmk9LENMTnCXeS5yUgqzroxSM5MOFdLzd4vmh690uVN2DNeP7BoS2Ub+cuXTVr1sf3l/RdDRbZPJjNqnzY+vSfq5COKN7DdLG8XDlAn9EOOSgd5j01rPdlfCYVBImH8Cwh6ZqMB0oA5TJZEPH/50vpAK4JnU4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from omf20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 754AFC03A7; Mon, 3 Jun 2024 05:37:42 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: Brian.Inglis@SystematicSW.ab.ca) by omf20.hostedemail.com (Postfix) with ESMTPA id E11A120025; Mon, 3 Jun 2024 05:37:39 +0000 (UTC) Message-ID: <7b329910-71ec-4df2-b931-c2ae1114e8b6@SystematicSW.ab.ca> Date: Sun, 2 Jun 2024 23:37:38 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: cygwin-apps@cygwin.com Subject: Re: newer version of mingw64-*-win-iconv ? To: cygwin-apps@cygwin.com References: <4642707.lMtyQzBqa6@nimes> <86d93340-5f12-40e7-b285-7ad9137b796c@SystematicSW.ab.ca> Content-Language: en-CA Cc: Bruno Haible From: Brian Inglis Organization: Systematic Software In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: 8majqs6suwp3im96ux98g8b8cb6fm86s X-Rspamd-Server: rspamout06 X-Rspamd-Queue-Id: E11A120025 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Session-Marker: 427269616E2E496E676C69734053797374656D6174696353572E61622E6361 X-Session-ID: U2FsdGVkX1/6Sj5VOFVobiZu1TXG9z2QALAWbZ4dkNU= X-HE-Tag: 1717393059-718360 X-HE-Meta: U2FsdGVkX19iZwTGm1au3RIW9FQxMFzfuQUVeDEI0AwH50ybkzWqbJRcmxZimqjGmrn0pMU71vl5xc56cY9UWOrBQ1eqgLzh6JLRF+8k//87fRRkvaK0nI+dijuI/3Q61HRXzGWszeWt9VSkT7WsgF1EG0w2w8s+tHXG1ZGyS8Cid4b0vRn6UOef0NygLVCaNjBsjt6rLiDPn/EdMFMKH9nQnoLAZBjpJrjp991z+pmUL8FbebwIwNiXJlniJtpqPvPmPU0o/UgOyDP7q2Wtq5SURhWkjbLgFKmEkwe9WSlU6UwGIZOv/xtCF9hQLxVRy9ihcped8ET9p1SrfTyUEQj912F+e0LuArhwsy0i7EPnGatJiyLGoTfp06ySE11sS6KFpUR9VjL60LrK7fsmCLGYmckSZbIUWm87HU/TtnLFfoAF5X3PFAhXzL168Sa3INeaPU7HwFbXXtwPBSELvdr1XQ7bCIBpuIijeUklaxT1c8QsYHdXDKmqpS5M7Xfx0QsZVFDfXKbl1xDpAuEGPfwEhEODKxKpzbR7o0XCfrqQRiYkEonw0w== X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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