Re: RE: Cygwin x86 end-of-life

Re: RE: Cygwin x86 end-of-life

[Brian Inglis]

On Fri, 18 Nov 2022 15:51:34 +0000, Jon Turney wrote:
> On 14/11/2022 21:29, Jason Pyeron wrote:
>> On Monday, November 14, 2022 3:17 PM, Brian Inglis wrote:
>>> 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.

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.

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

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.