* Re: RE: Cygwin x86 end-of-life
@ 2022-11-18 19:30 Brian Inglis
2022-11-21 12:45 ` Corinna Vinschen
0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2022-11-18 19:30 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RE: Cygwin x86 end-of-life
2022-11-18 19:30 RE: Cygwin x86 end-of-life Brian Inglis
@ 2022-11-21 12:45 ` Corinna Vinschen
2022-11-22 17:51 ` Brian Inglis
0 siblings, 1 reply; 6+ messages in thread
From: Corinna Vinschen @ 2022-11-21 12:45 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RE: Cygwin x86 end-of-life
2022-11-21 12:45 ` Corinna Vinschen
@ 2022-11-22 17:51 ` Brian Inglis
2022-11-22 21:07 ` Achim Gratz
0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2022-11-22 17:51 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin x86 end-of-life
2022-11-22 17:51 ` Brian Inglis
@ 2022-11-22 21:07 ` Achim Gratz
2022-11-23 20:00 ` Brian Inglis
0 siblings, 1 reply; 6+ messages in thread
From: Achim Gratz @ 2022-11-22 21:07 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin x86 end-of-life
2022-11-22 21:07 ` Achim Gratz
@ 2022-11-23 20:00 ` Brian Inglis
0 siblings, 0 replies; 6+ messages in thread
From: Brian Inglis @ 2022-11-23 20:00 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin x86 end-of-life
@ 2022-11-14 16:25 Jon Turney
2022-11-14 20:16 ` Brian Inglis
0 siblings, 1 reply; 6+ messages in thread
From: Jon Turney @ 2022-11-14 16:25 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cygwin x86 end-of-life
2022-11-14 16:25 Jon Turney
@ 2022-11-14 20:16 ` Brian Inglis
2022-11-14 21:29 ` Jason Pyeron
0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2022-11-14 20:16 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Cygwin x86 end-of-life
2022-11-14 20:16 ` Brian Inglis
@ 2022-11-14 21:29 ` Jason Pyeron
2022-11-18 15:51 ` Jon Turney
0 siblings, 1 reply; 6+ messages in thread
From: Jason Pyeron @ 2022-11-14 21:29 UTC (permalink / raw)
To: cygwin-apps
> -----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RE: Cygwin x86 end-of-life
2022-11-14 21:29 ` Jason Pyeron
@ 2022-11-18 15:51 ` Jon Turney
0 siblings, 0 replies; 6+ messages in thread
From: Jon Turney @ 2022-11-18 15:51 UTC (permalink / raw)
To: Jason Pyeron, cygwin-apps
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-11-23 20:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-18 19:30 RE: Cygwin x86 end-of-life Brian Inglis
2022-11-21 12:45 ` Corinna Vinschen
2022-11-22 17:51 ` Brian Inglis
2022-11-22 21:07 ` Achim Gratz
2022-11-23 20:00 ` Brian Inglis
-- strict thread matches above, loose matches on Subject: below --
2022-11-14 16:25 Jon Turney
2022-11-14 20:16 ` Brian Inglis
2022-11-14 21:29 ` Jason Pyeron
2022-11-18 15:51 ` Jon Turney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).