Re: Cygwin x86 end-of-life
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: Cygwin x86 end-of-life
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 à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: Cygwin x86 end-of-life
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: RE: Cygwin x86 end-of-life
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 +, 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 à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: RE: Cygwin x86 end-of-life
On Nov 18 12:30, Brian Inglis wrote: > On Fri, 18 Nov 2022 15:51:34 +, 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
On Fri, 18 Nov 2022 15:51:34 +, 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 +, 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 à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: RE: Cygwin x86 end-of-life
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 +, 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
> Op 14-11-2022 17:25 CET schreef Jon Turney : > 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
> -Original Message- > From: Brian Inglis > Sent: Monday, November 14, 2022 3:17 PM > > On Mon, 14 Nov 2022 16:25:18 +, 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: jpye...@pdinc.us tel : 202-741-9397
Re: Cygwin x86 end-of-life
On Mon, 14 Nov 2022 16:25:18 +, 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 à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: Cygwin x86 end-of-life
> 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
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
> > 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
On Fri, 11 Nov 2022 16:16:28 +, 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 à retirerbut when there is no more to cut -- Antoine de Saint-Exupéry
Re: Cygwin x86 end-of-life
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
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
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
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
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
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
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
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
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
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
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.
