Re: Cygwin x86 end-of-life

Re: Cygwin x86 end-of-life

[Jon Turney]

On 11/11/2022 15:50, Jon Turney wrote:
> 
> As has previously been announced, Cygwin is dropping support for x86 
> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
> 
> Concurrent with that, updates to x86 packages will be stopped, and the 
> Cygwin x86 package repository will be archived.

I plan to pause package uploads this coming Monday (2022-11-14), before 
starting the re-organization of the package repository to make this archive.

When package updates resume (I don't have an ETA, but I expect it will 
take a few days to attend to all the details), attempts to upload x86 
packages will be rejected with an error.

> (Instructions on the special steps needed to install from that archive 
> will be forthcoming, once we've worked out what they are.)
> 
> If you're using x86 Cygwin under WOW64 on a 64-bit Windows OS, please 
> strongly consider moving to an x86_64 Cygwin installation.
> 
> (If you have ARM hardware, we believe that x86_64 Cygwin works correctly 
> using the x86_64 emulation in Windows 11)
> 
> If you're one of the tiny percentage of Cygwin users using x86 Cygwin on 
> a real x86 Windows OS, don't panic! The current installation will 
> continue to run on your system. You just won't get any more updates.

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 11.11.2022 um 17:16 schrieb Jon Turney:
> On 11/11/2022 15:50, Jon Turney wrote:
>>
>> As has previously been announced, Cygwin is dropping support for x86 
>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 
>> only.
>>
>> Concurrent with that, updates to x86 packages will be stopped, and 
>> the Cygwin x86 package repository will be archived.
>
> I plan to pause package uploads this coming Monday (2022-11-14), 
> before starting the re-organization of the package repository to make 
> this archive.
Although expected for a while, the exact date is now a very short-time 
announcement. Can we have a moratorium for a short while?

>
> When package updates resume (I don't have an ETA, but I expect it will 
> take a few days to attend to all the details), attempts to upload x86 
> packages will be rejected with an error.
>
>> (Instructions on the special steps needed to install from that 
>> archive will be forthcoming, once we've worked out what they are.)
>>
>> If you're using x86 Cygwin under WOW64 on a 64-bit Windows OS, please 
>> strongly consider moving to an x86_64 Cygwin installation.
>>
>> (If you have ARM hardware, we believe that x86_64 Cygwin works 
>> correctly using the x86_64 emulation in Windows 11)
>>
>> If you're one of the tiny percentage of Cygwin users using x86 Cygwin 
>> on a real x86 Windows OS, don't panic! The current installation will 
>> continue to run on your system. You just won't get any more updates.
>

Re: Cygwin x86 end-of-life

[Achim Gratz]

Thomas Wolff writes:
>> I plan to pause package uploads this coming Monday (2022-11-14),
>> before starting the re-organization of the package repository to
>> make this archive.
> Although expected for a while, the exact date is now a very short-time
> announcement. Can we have a moratorium for a short while?

That moratorium is already running for more than a year:

https://cygwin.com/pipermail/cygwin/2021-October/249690.html


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Hi Achim,

Am 11.11.2022 um 20:50 schrieb Achim Gratz:
> Thomas Wolff writes:
>>> I plan to pause package uploads this coming Monday (2022-11-14),
>>> before starting the re-organization of the package repository to
>>> make this archive.
>> Although expected for a while, the exact date is now a very short-time
>> announcement. Can we have a moratorium for a short while?
> That moratorium is already running for more than a year:
>
> https://cygwin.com/pipermail/cygwin/2021-October/249690.html
That message does not announce a blocking of further 32-bit package 
uploads, and not a precise date for such hard step either. So please 
let's not commit a violation of the principle of least surprise.

> Regards,
> Achim.

Re: Cygwin x86 end-of-life

[Jon Turney]

On 11/11/2022 20:02, Thomas Wolff wrote:
> Hi Achim,
> 
> Am 11.11.2022 um 20:50 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>>> I plan to pause package uploads this coming Monday (2022-11-14),
>>>> before starting the re-organization of the package repository to
>>>> make this archive.
>>> Although expected for a while, the exact date is now a very short-time
>>> announcement. Can we have a moratorium for a short while?

So, if not now, when?

Is this actually going to cause you problems, and if so what are they 
specifically, or is this just a case of "change is bad"?

>> That moratorium is already running for more than a year:
>>
>> https://cygwin.com/pipermail/cygwin/2021-October/249690.html
> That message does not announce a blocking of further 32-bit package 
> uploads, and not a precise date for such hard step either. So please 
> let's not commit a violation of the principle of least surprise.

Sorry if this was communicated in a surprising way, but there is also 
another, important principle at work here, the principle of least 
effort, or as we might call it in this application "the principle of not 
inventing more work for Jon Turney to do".

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 12.11.2022 um 17:08 schrieb Jon Turney:
> On 11/11/2022 20:02, Thomas Wolff wrote:
>> Hi Achim,
>>
>> Am 11.11.2022 um 20:50 schrieb Achim Gratz:
>>> Thomas Wolff writes:
>>>>> I plan to pause package uploads this coming Monday (2022-11-14),
>>>>> before starting the re-organization of the package repository to
>>>>> make this archive.
>>>> Although expected for a while, the exact date is now a very short-time
>>>> announcement. Can we have a moratorium for a short while?
>
> So, if not now, when?
Well, first, I think it's not a good idea to change and over-interpret a 
plan in this way. The announcement for a year or so has been "cygwin 3.4 
will not support 32 bit anymore". This does not imply that the 
repository will be closed so any other package would not be allowed 
anymore to provide updates. What about security updates? Basic 
functionality?
I think a plan to freeze the repository would need a separate and 
explicit announcement, and some decent period from then.
>
> Is this actually going to cause you problems, and if so what are they 
> specifically, or is this just a case of "change is bad"?
Well I would certainly wish to upload a few more updates for mintty also 
for 32 bit, and also one other package of mine, to know their 32-bit 
packages are in a good final state. Mintty 3.6.1, for instance, has an 
exotic crash condition to be fixed but I wouldn't like to make an upload 
in a hurry this weekend.
>
>>> That moratorium is already running for more than a year:
>>>
>>> https://cygwin.com/pipermail/cygwin/2021-October/249690.html
>> That message does not announce a blocking of further 32-bit package 
>> uploads, and not a precise date for such hard step either. So please 
>> let's not commit a violation of the principle of least surprise.
>
> Sorry if this was communicated in a surprising way, but there is also 
> another, important principle at work here, the principle of least 
> effort, or as we might call it in this application "the principle of 
> not inventing more work for Jon Turney to do".
Understood, but is it really work to just not touch the repository for 
another few weeks?

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 12.11.2022 um 17:58 schrieb Thomas Wolff:
>
> Am 12.11.2022 um 17:08 schrieb Jon Turney:
>> On 11/11/2022 20:02, Thomas Wolff wrote:
>>> Hi Achim,
>>>
>>> Am 11.11.2022 um 20:50 schrieb Achim Gratz:
>>>> Thomas Wolff writes:
>>>>>> I plan to pause package uploads this coming Monday (2022-11-14),
>>>>>> before starting the re-organization of the package repository to
>>>>>> make this archive.
>>>>> Although expected for a while, the exact date is now a very 
>>>>> short-time
>>>>> announcement. Can we have a moratorium for a short while?
>>
>> So, if not now, when?
> Well, first, I think it's not a good idea to change and over-interpret 
> a plan in this way. The announcement for a year or so has been "cygwin 
> 3.4 will not support 32 bit anymore". This does not imply that the 
> repository will be closed so any other package would not be allowed 
> anymore to provide updates. What about security updates? Basic 
> functionality?
> I think a plan to freeze the repository would need a separate and 
> explicit announcement, and some decent period from then.
>>
>> Is this actually going to cause you problems, and if so what are they 
>> specifically, or is this just a case of "change is bad"?
> Well I would certainly wish to upload a few more updates for mintty 
> also for 32 bit, and also one other package of mine, to know their 
> 32-bit packages are in a good final state. Mintty 3.6.1, for instance, 
> has an exotic crash condition to be fixed but I wouldn't like to make 
> an upload in a hurry this weekend.
... Also I'd like to see the hopefully upcoming fix for the grep package 
in the final 32 bit version.

>>
>>>> That moratorium is already running for more than a year:
>>>>
>>>> https://cygwin.com/pipermail/cygwin/2021-October/249690.html
>>> That message does not announce a blocking of further 32-bit package 
>>> uploads, and not a precise date for such hard step either. So please 
>>> let's not commit a violation of the principle of least surprise.
>>
>> Sorry if this was communicated in a surprising way, but there is also 
>> another, important principle at work here, the principle of least 
>> effort, or as we might call it in this application "the principle of 
>> not inventing more work for Jon Turney to do".
> Understood, but is it really work to just not touch the repository for 
> another few weeks?

Re: Cygwin x86 end-of-life

[Achim Gratz]

Thomas Wolff writes:
> ... Also I'd like to see the hopefully upcoming fix for the grep
> package in the final 32 bit version.

sed -i -E 's/^(cmd|echo)/#\1/' /bin/[fe]grep


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 13.11.2022 um 17:43 schrieb Achim Gratz:
> Thomas Wolff writes:
>> ... Also I'd like to see the hopefully upcoming fix for the grep
>> package in the final 32 bit version.
> sed -i -E 's/^(cmd|echo)/#\1/' /bin/[fe]grep
I know it's a trivial change but as Corinna suggested, it should be in 
the package.
And we shouldn't end up with a frozen repository with the current grep crap.

> Regards,
> Achim.

Re: Cygwin x86 end-of-life

[Jon Turney]

On 12/11/2022 16:58, Thomas Wolff wrote:
> Am 12.11.2022 um 17:08 schrieb Jon Turney:
>> On 11/11/2022 20:02, Thomas Wolff wrote:
>>> Am 11.11.2022 um 20:50 schrieb Achim Gratz:
>>>> Thomas Wolff writes:
>>>>>> I plan to pause package uploads this coming Monday (2022-11-14),
>>>>>> before starting the re-organization of the package repository to
>>>>>> make this archive.
>>>>> Although expected for a while, the exact date is now a very short-time
>>>>> announcement. Can we have a moratorium for a short while?
>>
>> So, if not now, when?
> Well, first, I think it's not a good idea to change and over-interpret a 
> plan in this way. The announcement for a year or so has been "cygwin 3.4 
> will not support 32 bit anymore". This does not imply that the 
> repository will be closed so any other package would not be allowed 
> anymore to provide updates. What about security updates? Basic 
> functionality?

Security is a complete red-herring here. We are not good at making 
timely updates for that purpose, generally.  To suggest that x86 will be 
receiving security updates, when we've also said x86 is deprecated, and 
some maintainers aren't updating it at all, makes no sense at all.

The message needs to be: If you care about security, at the very least, 
don't use x86 Cygwin. This is one of the reasons why I want to archive x86.

If you think there is some broken "basic functionality" in the current 
package set, please say what it is.  If something critical is discovered 
after the freeze, I am not totally ruling out permitting an exceptional 
upload (although the case for criticality would have to be well made, 
as, again this involves yet more work for me, to benefit a small 
percentage of installations, and one would think that such critical 
problems would be evident currently).

> I think a plan to freeze the repository would need a separate and 
> explicit announcement, and some decent period from then.
>>
>> Is this actually going to cause you problems, and if so what are they 
>> specifically, or is this just a case of "change is bad"?
> Well I would certainly wish to upload a few more updates for mintty also 
> for 32 bit, and also one other package of mine, to know their 32-bit 
> packages are in a good final state. Mintty 3.6.1, for instance, has an 
> exotic crash condition to be fixed but I wouldn't like to make an upload 
> in a hurry this weekend.

>>>> That moratorium is already running for more than a year:
>>>>
>>>> https://cygwin.com/pipermail/cygwin/2021-October/249690.html
>>> That message does not announce a blocking of further 32-bit package 
>>> uploads, and not a precise date for such hard step either. So please 
>>> let's not commit a violation of the principle of least surprise.
>>
>> Sorry if this was communicated in a surprising way, but there is also 
>> another, important principle at work here, the principle of least 
>> effort, or as we might call it in this application "the principle of 
>> not inventing more work for Jon Turney to do".
> Understood, but is it really work to just not touch the repository for 
> another few weeks?

This veers between "indefinitely", "until I'm happy with my packages", 
"a decent period", "a short while", and "a few weeks", so I'm still 
unclear what you are actually asking for here.

Re: Cygwin x86 end-of-life

[Corinna Vinschen]

On Nov 13 17:07, Jon Turney wrote:
> On 12/11/2022 16:58, Thomas Wolff wrote:
> > Am 12.11.2022 um 17:08 schrieb Jon Turney:
> > > On 11/11/2022 20:02, Thomas Wolff wrote:
> > > > Am 11.11.2022 um 20:50 schrieb Achim Gratz:
> > > > > Thomas Wolff writes:
> > > > > > > I plan to pause package uploads this coming Monday (2022-11-14),
> > > > > > > before starting the re-organization of the package repository to
> > > > > > > make this archive.
> > > > > > Although expected for a while, the exact date is now a very short-time
> > > > > > announcement. Can we have a moratorium for a short while?
> > > 
> > > So, if not now, when?
> > Well, first, I think it's not a good idea to change and over-interpret a
> > plan in this way. The announcement for a year or so has been "cygwin 3.4
> > will not support 32 bit anymore". This does not imply that the
> > repository will be closed so any other package would not be allowed
> > anymore to provide updates. What about security updates? Basic
> > functionality?
> 
> Security is a complete red-herring here. We are not good at making timely
> updates for that purpose, generally.  To suggest that x86 will be receiving
> security updates, when we've also said x86 is deprecated, and some
> maintainers aren't updating it at all, makes no sense at all.
> 
> The message needs to be: If you care about security, at the very least,
> don't use x86 Cygwin. This is one of the reasons why I want to archive x86.
> 
> If you think there is some broken "basic functionality" in the current
> package set, please say what it is.  If something critical is discovered
> after the freeze, I am not totally ruling out permitting an exceptional
> upload (although the case for criticality would have to be well made, as,
> again this involves yet more work for me, to benefit a small percentage of
> installations, and one would think that such critical problems would be
> evident currently).

Well said.


Corinna

Re: Cygwin x86 end-of-life

[Andrew Schulman]

> 
> Am 11.11.2022 um 17:16 schrieb Jon Turney:
> > On 11/11/2022 15:50, Jon Turney wrote:
> >>
> >> As has previously been announced, Cygwin is dropping support for x86 
> >> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
> >> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 
> >> only.
> >>
> >> Concurrent with that, updates to x86 packages will be stopped, and 
> >> the Cygwin x86 package repository will be archived.
> >
> > I plan to pause package uploads this coming Monday (2022-11-14), 
> > before starting the re-organization of the package repository to make 
> > this archive.
> Although expected for a while, the exact date is now a very short-time 
> announcement. Can we have a moratorium for a short while?

Agree. Maybe I should have known from previous announcements that the forever
cutoff date was today, but I didn't. I'm now in the process of updating a couple
of packages that need it, so the i686 archive will reflect the latest available
versions. It would be helpful if we had a couple more days to update before the
portcullis comes down.

Thanks, Andrew

Re: Cygwin x86 end-of-life

[Brian Inglis]

On Fri, 11 Nov 2022 16:16:28 +0000, Jon Turney wrote:
> On 11/11/2022 15:50, Jon Turney wrote:
>> As has previously been announced, Cygwin is dropping support for x86 
>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
>> 
>> Concurrent with that, updates to x86 packages will be stopped, and the 
>> Cygwin x86 package repository will be archived.
> 
> I plan to pause package uploads this coming Monday (2022-11-14), before 
> starting the re-organization of the package repository to make this archive.
> 
> When package updates resume (I don't have an ETA, but I expect it will 
> take a few days to attend to all the details), attempts to upload x86 
> packages will be rejected with an error.

>> (Instructions on the special steps needed to install from that archive 
>> will be forthcoming, once we've worked out what they are.)
>> 
>> If you're using x86 Cygwin under WOW64 on a 64-bit Windows OS, please 
>> strongly consider moving to an x86_64 Cygwin installation.
>> 
>> (If you have ARM hardware, we believe that x86_64 Cygwin works correctly 
>> using the x86_64 emulation in Windows 11)
>> 
>> If you're one of the tiny percentage of Cygwin users using x86 Cygwin on 
>> a real x86 Windows OS, don't panic! The current installation will 
>> continue to run on your system. You just won't get any more updates.

Give that it took anyone two months after my notices to this list that grep 
would be issuing warnings, and a month after release, before anyone responded, 
and that includes project leadership, providing less than a week's notice is 
obviously insufficient for most to even notice, given that it appears that many 
may not regularly read this list, have any time this month, be busy, or away on 
business or vacation, for weeks.

This appears to be a fairly major undertaking with previously unanticipated and 
unannounced impacts.
It also appears that detailed plans about what this work entails and impacts 
have not yet been fully worked out, no timeline is available, and the details 
and timeline of what is being done is only just being mentioned on this list, 
and not being detailed here or on the general public list for notice and feedback.

I think it is only fair that full details of the impact and timelines should 
first be worked out for whatever next steps need to be taken, and posted to this 
list, the announce, and general public lists, with sufficient notice before 
taking action.

-- 
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 x86 end-of-life

[Jon Turney]

On 11/11/2022 16:16, Jon Turney wrote:
> On 11/11/2022 15:50, Jon Turney wrote:
>>
>> As has previously been announced, Cygwin is dropping support for x86 
>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
>>
>> Concurrent with that, updates to x86 packages will be stopped, and the 
>> Cygwin x86 package repository will be archived.
> 
> I plan to pause package uploads this coming Monday (2022-11-14), before 
> starting the re-organization of the package repository to make this 
> archive.

Since there have been some complaints about short notice, and to give 
time to work out the issues with gettext/libunistring, I'm going to 
defer this by one week, until Monday 2022-11-21.

Re: Cygwin x86 end-of-life

[Andrew Schulman]

> On 11/11/2022 16:16, Jon Turney wrote:
> > On 11/11/2022 15:50, Jon Turney wrote:
> >>
> >> As has previously been announced, Cygwin is dropping support for x86 
> >> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
> >> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
> >>
> >> Concurrent with that, updates to x86 packages will be stopped, and the 
> >> Cygwin x86 package repository will be archived.
> > 
> > I plan to pause package uploads this coming Monday (2022-11-14), before 
> > starting the re-organization of the package repository to make this 
> > archive.
> 
> Since there have been some complaints about short notice, and to give 
> time to work out the issues with gettext/libunistring, I'm going to 
> defer this by one week, until Monday 2022-11-21.

Thank you!

Re: Cygwin x86 end-of-life

[Brian Inglis]

On Mon, 14 Nov 2022 16:25:18 +0000, Jon Turney wrote:> On 11/11/2022 16:16, Jon 
Turney wrote:
>> On 11/11/2022 15:50, Jon Turney wrote:
>>> As has previously been announced, Cygwin is dropping support for x86 
>>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
>>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
>>>
>>> Concurrent with that, updates to x86 packages will be stopped, and the 
>>> Cygwin x86 package repository will be archived.

>> I plan to pause package uploads this coming Monday (2022-11-14), before 
>> starting the re-organization of the package repository to make this 
>> archive.

> Since there have been some complaints about short notice, and to give 
> time to work out the issues with gettext/libunistring, I'm going to 
> defer this by one week, until Monday 2022-11-21.

Thank you very much appreciated, hopefully we can deal with the remaining issues 
quickly.

-- 
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 x86 end-of-life

[Jason Pyeron]

> -----Original Message-----
> From: Brian Inglis
> Sent: Monday, November 14, 2022 3:17 PM
> 
> On Mon, 14 Nov 2022 16:25:18 +0000, Jon Turney wrote:> On 11/11/2022 16:16, Jon
> Turney wrote:
> >> On 11/11/2022 15:50, Jon Turney wrote:
> >>> As has previously been announced, Cygwin is dropping support for x86
> >>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit)
> >>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
> >>>
> >>> Concurrent with that, updates to x86 packages will be stopped, and the
> >>> Cygwin x86 package repository will be archived.
> 
> >> I plan to pause package uploads this coming Monday (2022-11-14), before
> >> starting the re-organization of the package repository to make this
> >> archive.
> 
> > Since there have been some complaints about short notice, and to give
> > time to work out the issues with gettext/libunistring, I'm going to
> > defer this by one week, until Monday 2022-11-21.
> 
> Thank you very much appreciated, hopefully we can deal with the remaining issues
> quickly.

I do not have an articulate retort to ending support, but all I can say is that I feel there must be a middle ground.

I feel that there could and should be some form of "we don’t support it" but we are not going out of our way to prevent it.

Can I throw resources at a solution? If so what?

Feel free to ignore my grumpy ramblings.

-Jason

--
Jason Pyeron  | Architect
PD Inc        | Certified SBA 8(a)
10 w 24th St  | Certified SBA HUBZone
Baltimore, MD | CAGE Code: 1WVR6
 
.com: jpyeron@pdinc.us
tel : 202-741-9397

Re: RE: Cygwin x86 end-of-life

[Jon Turney]

On 14/11/2022 21:29, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Brian Inglis
>> Sent: Monday, November 14, 2022 3:17 PM
>>
>> On Mon, 14 Nov 2022 16:25:18 +0000, Jon Turney wrote:> On 11/11/2022 16:16, Jon
>> Turney wrote:
>>>> On 11/11/2022 15:50, Jon Turney wrote:
>>>>> As has previously been announced, Cygwin is dropping support for x86
>>>>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit)
>>>>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only.
>>>>>
>>>>> Concurrent with that, updates to x86 packages will be stopped, and the
>>>>> Cygwin x86 package repository will be archived.
>>
>>>> I plan to pause package uploads this coming Monday (2022-11-14), before
>>>> starting the re-organization of the package repository to make this
>>>> archive.
>>
>>> Since there have been some complaints about short notice, and to give
>>> time to work out the issues with gettext/libunistring, I'm going to
>>> defer this by one week, until Monday 2022-11-21.
>>
>> Thank you very much appreciated, hopefully we can deal with the remaining issues
>> quickly.
> 
> I do not have an articulate retort to ending support, but all I can say is that I feel there must be a middle ground.
> 
> I feel that there could and should be some form of "we don’t support it" but we are not going out of our way to prevent it.

I'm unclear if this means:

(a) "releasing Cygwin 3.4.x DLL for x86 OS"
(b) "don't require x86 uploads, but don't prevent them, either"

The problem I have with (b) is that we probably end up in a state where 
x86 is missing package updates people want or need; or broken, but we 
don't know it, because nobody uses it.

> Can I throw resources at a solution? If so what?

Sure, if that's what you want to do.

According surveys, 32-bit Windows has a fraction of 1% market share, and 
declining. Our own (limited) metrics are in accord with that, so I 
basically see any time I spend on this as wasted.

So, the first resource you'll need provide is manpower.

Re: Cygwin x86 end-of-life

[Erwin Waterlander]

> Op 14-11-2022 17:25 CET schreef Jon Turney <jon.turney@dronecode.org.uk>:
> Since there have been some complaints about short notice, and to give
> time to work out the issues with gettext/libunistring, I'm going to
> defer this by one week, until Monday 2022-11-21.

I uploaded libunistring 1.1-1.

Erwin

Re: Cygwin x86 end-of-life

[Jon Turney]

On 14/11/2022 16:25, Jon Turney wrote:
> On 11/11/2022 16:16, Jon Turney wrote:
>> On 11/11/2022 15:50, Jon Turney wrote:
>>>
>>> As has previously been announced, Cygwin is dropping support for x86 
>>> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
>>> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 
>>> only.
>>>
>>> Concurrent with that, updates to x86 packages will be stopped, and 
>>> the Cygwin x86 package repository will be archived.
>>
>> I plan to pause package uploads this coming Monday (2022-11-14), 
>> before starting the re-organization of the package repository to make 
>> this archive.
> 
> Since there have been some complaints about short notice, and to give 
> time to work out the issues with gettext/libunistring, I'm going to 
> defer this by one week, until Monday 2022-11-21.

Package uploads are resumed.

Re: RE: Cygwin x86 end-of-life

[Corinna Vinschen]

On Nov 18 12:30, Brian Inglis wrote:
> On Fri, 18 Nov 2022 15:51:34 +0000, Jon Turney wrote:
> > On 14/11/2022 21:29, Jason Pyeron wrote:
> > > Can I throw resources at a solution? If so what?
> 
> > Sure, if that's what you want to do.
> > According surveys, 32-bit Windows has a fraction of 1% market share, and
> > declining. Our own (limited) metrics are in accord with that, so I
> > basically see any time I spend on this as wasted.
> > So, the first resource you'll need provide is manpower.
> 
> The decision makes sense with those numbers.
> Do we have numbers to say what the situation is with Windows mingw64-i686 crosses?
> Should we also be dropping those at the same time, if there is only 1% use
> of that platform?
> In which case, we should announce that, and add that to the EoL notices.

A cygwin -> i686-w64-mingw32 cross is an entirely different beast.
It's kind of like a cygwin -> sparc-sun-sunos4 cross, or a cygwin ->
riscv-*-* cross.  Either of them is a perfectly valid toolchain, hosted
on Cygwin, targeting some foreign CPU/machine combination.

As long as the cross toolchain has a maintainer, it's ok, isn't it?


Corinna

Re: RE: Cygwin x86 end-of-life

[Brian Inglis]

On Mon, 21 Nov 2022 13:45:09 +0100, Corinna Vinschen wrote:> On Nov 18 12:30, 
Brian Inglis wrote:
>> On Fri, 18 Nov 2022 15:51:34 +0000, Jon Turney wrote:
>>> On 14/11/2022 21:29, Jason Pyeron wrote:
>>>> Can I throw resources at a solution? If so what?

>>> Sure, if that's what you want to do.
>>> According surveys, 32-bit Windows has a fraction of 1% market share, and 
>>> declining. Our own (limited) metrics are in accord with that, so I 
>>> basically see any time I spend on this as wasted.
>>> So, the first resource you'll need provide is manpower.

>> The decision makes sense with those numbers.
>> Do we have numbers to say what the situation is with Windows mingw64-i686 crosses?
>> Should we also be dropping those at the same time, if there is only 1% use
>> of that platform?
>> In which case, we should announce that, and add that to the EoL notices.

> A cygwin -> i686-w64-mingw32 cross is an entirely different beast.
> It's kind of like a cygwin -> sparc-sun-sunos4 cross, or a cygwin ->
> riscv-*-* cross.  Either of them is a perfectly valid toolchain, hosted
> on Cygwin, targeting some foreign CPU/machine combination.
> As long as the cross toolchain has a maintainer, it's ok, isn't it?

As mingw64-i686 target is cross for native Windows 32, and we are dropping 
Cygwin support for Windows 32, should we not also be dropping cross support for 
native Windows 32, as so few people are using it, and software developers, 
packagers, and distros, including us, are dropping it as platform and target?

As Jon says "I basically see any time I spend on this as wasted."

Also there are 309 unmaintained mingw64 packages, so perhaps reducing the double 
(over the base package) extra work of maintaining mingw64 packages to a single 
extra cross might enable us to persuade some maintainers to pick up unmaintained 
native Windows 64 cross mingw64-x86_64 packages corresponding to the base 
packages they maintain?

-- 
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 x86 end-of-life

[Achim Gratz]

Brian Inglis writes:
> As mingw64-i686 target is cross for native Windows 32, and we are
> dropping Cygwin support for Windows 32, should we not also be dropping
> cross support for native Windows 32, as so few people are using it,
> and software developers, packagers, and distros, including us, are
> dropping it as platform and target?

I am unlikely to update that toolchain when I move gcc to version 12 or
later.

> Also there are 309 unmaintained mingw64 packages, so perhaps reducing
> the double (over the base package) extra work of maintaining mingw64
> packages to a single extra cross might enable us to persuade some
> maintainers to pick up unmaintained native Windows 64 cross
> mingw64-x86_64 packages corresponding to the base packages they
> maintain?

I can't speak for others, but on my end there's not been much of a
problem with having the MingW64 packages in two flavors in addition to
the Cygwin dual architecture builds.  Maybe we'll end up supporting
ARM64 some way down the road and then it's going to be yet another
target again for packagers.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Cygwin x86 end-of-life

[Brian Inglis]

On Tue, 22 Nov 2022 22:07:56 +0100, Achim Gratz wrote:
> Brian Inglis writes:
>> As mingw64-i686 target is cross for native Windows 32, and we are
>> dropping Cygwin support for Windows 32, should we not also be dropping
>> cross support for native Windows 32, as so few people are using it,
>> and software developers, packagers, and distros, including us, are
>> dropping it as platform and target?
> 
> I am unlikely to update that toolchain when I move gcc to version 12 or
> later.

So mingw64-i686 cross for native Windows 32 will soon be EoL, and an 
announcement should be made at some point.
That may give us some feedback on whether there is much use of the Cygwin 
packages or whether those available from the Mingw64 project are preferred.

>> Also there are 309 unmaintained mingw64 packages, so perhaps reducing
>> the double (over the base package) extra work of maintaining mingw64
>> packages to a single extra cross might enable us to persuade some
>> maintainers to pick up unmaintained native Windows 64 cross
>> mingw64-x86_64 packages corresponding to the base packages they
>> maintain?
> 
> I can't speak for others, but on my end there's not been much of a
> problem with having the MingW64 packages in two flavors in addition to
> the Cygwin dual architecture builds.  Maybe we'll end up supporting
> ARM64 some way down the road and then it's going to be yet another
> target again for packagers.

A single package build uses all available cpu on my system (0-9% idle), and 
large packages or those with extensive tests take an hour per arch, so it's 4 
hours duration, plus another 3(+/-1) to run on scallywag, sometimes overlapped.
Not usually a problem unless a couple of those upgrade the same week.
Dropping x86 and mingw64-i686 half that.

Once that direction has been determined, perhaps we can suggest here that 
package maintainers pick up related unmaintained mingw64-x86_64 packages, and 
post a list of the suggestions, or a report like the deprecated library and 
unmaintained packages reports linked from the search page.

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