Re: sqlite3 outdate

[Brian Inglis via Cygwin]

On 2023-10-12 18:41, xvac wrote:

Oct 13, 2023, 08:39 by xvac:

I find sqlite3 and postgresql packages in cygwin is outdate, anyone can up it 
to latest?


I would say postgresql is only lagging a few months because the maintainer is 
busy with many other packages:


https://cygwin.com/packages/summary/postgresql-src.html


also, many new CLI tools should add to cygwin official repo e.g., `bun` :
https://github.com/oven-sh/bun
With ~1.9k open issues, 155 pending PRs, and ~100 releases in 2 years, wait for 
it to stablize before looking at it.


Problem is most packages are not written to really be portable, including 
ability to be cross-compiled, and languages especially are often written as 
Ph.D. projects, or academic projects to provide a subject for papers and a book 
by (a) professor(s), and abandoned once the developers get jobs or move away 
from the originating institution.



zig lang


Needs LLVM 17


nim lang


"Cygwin and similar POSIX runtime environments are not supported."


rust lang


"Cygwin and similar POSIX runtime environments are not supported."

Needs LLVM 17


also should add to cygwin official repo.


Feel free to port them, but if they don't use autotools or cmake, libtool, and 
pkgconfig, expect a lot of work to get them running in the Cygwin environment.


See the reference to the person trying to port Rust needing to get LLVM 17 
ported.

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

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: sqlite3 outdate

[Takashi Yano via Cygwin]

On Fri, 13 Oct 2023 04:33:47 +0200
Thomas Wolff wrote:
> Am 13.10.2023 um 02:41 schrieb xvac--- via Cygwin:
> > zig lang
> > nim lang
> > rust lang
> >
> > also should add to cygwin official repo.
> The Rust project does not support build on cygwin (see 
> https://github.com/rust-lang/rust/issues/79854).

Chiisaineko (Ookiineko?) san seems to be working on porting
Rust to cygwin.

https://cygwin.com/pipermail/cygwin-apps/2023-July/043048.html

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: sqlite3 outdate

[Thomas Wolff via Cygwin]

Am 13.10.2023 um 02:41 schrieb xvac--- via Cygwin:

zig lang
nim lang
rust lang

also should add to cygwin official repo.
The Rust project does not support build on cygwin (see 
https://github.com/rust-lang/rust/issues/79854).

Never heard of zig or nim.



Oct 13, 2023, 08:39 by x...@tuta.io:


Hi cygwin member,

I find sqlite3 and postgresql packages in cygwin is outdate, anyone can up it 
to latest?

also, many new CLI tools should add to cygwin official repo.
eg, `bun` :
https://github.com/oven-sh/bun








--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: sqlite3 outdate

[xvac--- via Cygwin]

zig lang
nim lang
rust lang

also should add to cygwin official repo.


Oct 13, 2023, 08:39 by x...@tuta.io:

> Hi cygwin member,
>
> I find sqlite3 and postgresql packages in cygwin is outdate, anyone can up it 
> to latest?
>
> also, many new CLI tools should add to cygwin official repo.
> eg, `bun` :
> https://github.com/oven-sh/bun
>
>
>


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

sqlite3 outdate

[xvac--- via Cygwin]

Hi cygwin member,

I find sqlite3 and postgresql packages in cygwin is outdate, anyone can up it 
to latest?

also, many new CLI tools should add to cygwin official repo.eg, `bun` :
https://github.com/oven-sh/bun



-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Ruby EOL in Cygwin 3.4.9?

[David Rothenberger via Cygwin]

On 10/12/2023 2:46 PM, Eric Hendrickson via Cygwin wrote:

And your point about the effort involved and no known bugs is well taken of 
course but Cygwin is still distributing EOL software.  This is why I asked, 
would it make sense to just not release new non emergency versions of Cygwin 
with EOL packages, until that can be remedied.


Cygwin "releases" are just releases of the compatibility library, 
similar to the kernel in a Linux distribution. Cygwin doesn't have the 
equivalent of Debian releases, where all packages are tested for 
compatibility and released as a unit.


For that reason, it doesn't make sense to pause Cygwin "releases" just 
because some of the packages are out-of-date, since Cygwin is itself 
just another one of these packages.


--
David Rothenberger    daver...@acm.org

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Ruby EOL in Cygwin 3.4.9?

[Eric Hendrickson via Cygwin]

Thank you, Adam, for your constructive response.

So, I hear what you are saying of course. I’m not asking people to do more 
work, I was just asking if these factors (EOL software) are important to 
Cygwin. I realize that’s nuanced but nevertheless this is so.

The comparison to Debian Stable - I hear you but I don’t think that is a fair 
comparison. Debian Stable is not shipping EOL packages at the time it was 
released.

And your point about the effort involved and no known bugs is well taken of 
course but Cygwin is still distributing EOL software.  This is why I asked, 
would it make sense to just not release new non emergency versions of Cygwin 
with EOL packages, until that can be remedied.

But again I get the amount of work required. That’s helpful. I do think pausing 
releases or even targeting getting all packages updated in tranches perhaps, it 
would take a lot of work the first pass but then going forward keeping it 
current might not be so impactful to the normal release process.

I just worry about the reputational impact to Cygwin if releasing EOL software 
in this day and age were there a 0day or something and here this version of 
Cygwin was just released recently…

Security scans are only increasing in scrutiny and frequency - this came to my 
attention because in my environment we are running Cygwin 3.1.6 - which 
admittedly is 3+ years old - and the version of Ruby packaged in it got 
identified in a security scan as EOL.

My first thought was to update the internal Cygwin package to the latest but i 
checked and that too is provisioned with an EOL version of Ruby. (2.6.4)

Anyway, just wanted to bring this to your attention and ask if there is 
anything that can or should be done about this, again toward the reputation of 
Cygwin.

Appreciate your time and sharing.

Thank you,
Eric

Sent from Outlook on my Tricorder

From: Adam Dinwoodie 
Sent: Thursday, October 12, 2023 1:22 PM
To: Eric D Hendrickson 
Cc: gs-cygwin@gluelogic.com ; Hendrickson, 
Eric D ; cygwin@cygwin.com 
Subject: Re: Ruby EOL in Cygwin 3.4.9?

Picking up a few threads that I think others might have missed, and
which I think are worthy of acknowledgement…

On Thu, 12 Oct 2023 at 05:16, Eric D Hendrickson via Cygwin
 wrote:
> How does Cygwin being an all volunteer effort have any bearing on this
> question, other than the time and interest of the volunteers?

The fact that this is a volunteer effort doesn't have much direct
bearing. But the fact that we're volunteers means that time and
interest are very finite quantities. There are really not many folk
involved in actually making Cygwin, and I think everyone actively
involved in the project already has a wishlist of things they'd do if
they had the time.

> Perhaps the volunteer team should consider adopting a process of evaluating
> the support status of every package it redistributes, even at the expense
> of slowing down the rate of releases.  Or dropping packages when no one has
> the time or interest in creating a package from a supported version of the
> tool in question.

Packages do get dropped from the distribution occasionally when
they're no longer being updated and no longer viable.

I don't believe there's any comprehensive package-by-package review,
because that's a lot of work, and it's not even very interesting work.
But if someone provides a reason a specific package should be dropped,
it can happen. The mere fact that a package no longer has upstream
support is probably not enough, though; I expect we'd need no upstream
support and either a genuine significant vulnerability in the package,
or availability of a viable replacement.

> Again for the benefit of Cygwin as a whole - distributing EOL packages
> could put Cygwin as a whole at risk, which I'm sure you would agree is much
> worse than dropping a package from the suite.

I don't agree. If Cygwin mandated that packages be kept rapidly
up-to-date or be dropped, I expect Cygwin would rapidly become
unusable. A lot of our package maintainers – myself included – are
only able to work on Cygwin as and when they have the time. If the
project required maintainers to spend a regular amount of time on
their packages, which a reliable update schedule would require, I
expect a lot of us would just stop contributing.

When there are vulnerabilities identified, we can and do move quickly
to mitigate them. The fact that there's some EOL products available
through Cygwin is at least in part because there aren't any
significant security vulnerabilities that we're aware of. It would, of
course, be nice if the cutting edge were available for everything, but
that has its own disadvantages: rapid release cycles have more chance
of introducing new bugs. There's a reason plenty of people use Debian
Stable; there's lots of critical infrastructure still running on
Python 2.

(But, of course, the package in question here is actually reasonably
up-to-date: as Y

Re: Ruby EOL in Cygwin 3.4.9?

[Adam Dinwoodie via Cygwin]

Picking up a few threads that I think others might have missed, and
which I think are worthy of acknowledgement…

On Thu, 12 Oct 2023 at 05:16, Eric D Hendrickson via Cygwin
 wrote:
> How does Cygwin being an all volunteer effort have any bearing on this
> question, other than the time and interest of the volunteers?

The fact that this is a volunteer effort doesn't have much direct
bearing. But the fact that we're volunteers means that time and
interest are very finite quantities. There are really not many folk
involved in actually making Cygwin, and I think everyone actively
involved in the project already has a wishlist of things they'd do if
they had the time.

> Perhaps the volunteer team should consider adopting a process of evaluating
> the support status of every package it redistributes, even at the expense
> of slowing down the rate of releases.  Or dropping packages when no one has
> the time or interest in creating a package from a supported version of the
> tool in question.

Packages do get dropped from the distribution occasionally when
they're no longer being updated and no longer viable.

I don't believe there's any comprehensive package-by-package review,
because that's a lot of work, and it's not even very interesting work.
But if someone provides a reason a specific package should be dropped,
it can happen. The mere fact that a package no longer has upstream
support is probably not enough, though; I expect we'd need no upstream
support and either a genuine significant vulnerability in the package,
or availability of a viable replacement.

> Again for the benefit of Cygwin as a whole - distributing EOL packages
> could put Cygwin as a whole at risk, which I'm sure you would agree is much
> worse than dropping a package from the suite.

I don't agree. If Cygwin mandated that packages be kept rapidly
up-to-date or be dropped, I expect Cygwin would rapidly become
unusable. A lot of our package maintainers – myself included – are
only able to work on Cygwin as and when they have the time. If the
project required maintainers to spend a regular amount of time on
their packages, which a reliable update schedule would require, I
expect a lot of us would just stop contributing.

When there are vulnerabilities identified, we can and do move quickly
to mitigate them. The fact that there's some EOL products available
through Cygwin is at least in part because there aren't any
significant security vulnerabilities that we're aware of. It would, of
course, be nice if the cutting edge were available for everything, but
that has its own disadvantages: rapid release cycles have more chance
of introducing new bugs. There's a reason plenty of people use Debian
Stable; there's lots of critical infrastructure still running on
Python 2.

(But, of course, the package in question here is actually reasonably
up-to-date: as Yasuhiro Kimura noted, the Cygwin mirrors are
distributing ruby 3.2.2-2, which has an advertised upstream EOL date
of March 2026. So a possibly more useful question is why *you* are
deploying an EOL version when more up-to-date versions are available!
To investigate that, I think we'd need a useful bug report explaining
what you're doing to get an install with such an old version.)

I also think it's worth remembering the use case for Cygwin. Cygwin is
designed to provide a *nix-like environment for Windows users, with
relatively little effort required to port software that was originally
written for *nix systems. The sorts of use cases where you really care
about most zero-day vulnerabilities aren't ones where I'd expect
Cygwin to be in use; if you have a public-facing web server, for
example, using Cygwin is a bad idea, not just because of the security
concerns, but also because Cygwin makes a lot of compromises around
performance, and you're likely to have a vastly better experience
using a Windows-native or Linux-native web server.

> This goes back to my other question -
>
> Is there an Issues log or backlog a la GitHub where bugs / enhancement
> requests / feature suggestions like this can be logged for future
> consideration / evaluation, instead of one off discussions in this
> ephemeral medium of email?

Email isn't ephemeral: everything sent to this mailing list is
archived indefinitely. You can browse and search the archives at
https://cygwin.com/lists.html.

That said, there is a reason folk use bug trackers. There's no central
bug tracker for Cygwin; individual maintainers may have their own
systems for tracking problems (I use GitHub), but there's no mandate
about what to use or how to use it. Even if we had someone willing to
set one up and maintain one, migrating to a central bug tracker is a
very significant amount of work, and it's not work that many people
would find fun or interesting.

If you want to help, there's a list of packages that don't have
maintainers at http://www.cygwin.com/packages/reports/unmaintained.html
– if you'd be willing to adopt one of those and keep it

Re: Ruby EOL in Cygwin 3.4.9?

[Thomas Schweikle via Cygwin]

Am Mi., 11.Okt..2023 um 18:37:29 schrieb Hendrickson, Eric D via Cygwin:

Hello all,

As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at 
my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL 
about 18 months ago?

https://www.ruby-lang.org/en/downloads/branches/

I'm concerned about proliferation of EOL versions of Ruby in case some security 
risk / 0Day is identified.


Did you set version 2.6* to install? It is still there and may be 
installed. Version 3.2.2 is available too.


--
Thomas



OpenPGP_0x27AE2304B4974851.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Ruby EOL in Cygwin 3.4.9?

[Brian Inglis via Cygwin]

On Wed, Oct 11, 2023 at 10:59 PM wrote:

On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson wrote:

Sorry for the unclarity - I meant this for the whole list - not just you.
Thank you so much for taking the time to respond.  Like you said, this
really is all volunteers.
For the whole list:
Totally taking into account the all volunteer nature of Cygwin, would it
make sense to defer on further non-emergency releases of Cygwin until all
packages that are EOL have been updated?  Since this is the case with

ruby,

I am guessing it's likely the case with other packages in Cygwin too.
Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
that I can document this in the backlog and come back later to

investigate

this myself if I have time this winter?
On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss wrote:

On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:

Thanks for responding.  That makes total sense.
Totally taking into account the all volunteer nature of Cygwin,

would it

make sense to defer on further non-emergency releases of Cygwin until

all

packages that are EOL have been updated?  Since this is the case with

ruby,

I am guessing it's likely the case with other packages in Cygwin too.


Is there a backlog for Cygwin somewhere, so that I can investigate

this

myself if I have time this winter?

On Wednesday, October 11, 2023 5:03 PM, Eliot Moss wrote:
On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:

As a ~25 year user and sometime contributor to Cygwin, I support

Cygwin

here at my place of work.  Does anyone know why we are deploying Ruby

2.6

which EOL about 18 months ago?


https://www.ruby-lang.org/en/downloads/branches/

I'm concerned about proliferation of EOL versions of Ruby in case

some

security risk / 0Day is identified.


Please advise.

You should send such things to the list, not me.  I'm just
a user who has only made occasional small contributions ...

If nobody has responded I can give a generic response:
"Because cygwin is all volunteer and someone has not volunteered, or

did

volunteer and is behind, or fell off the radar."


Someone else will know how to look up if there is a currently

registered

volunteer for Ruby ...

On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
wrote:

Totally taking into account the all volunteer nature of Cygwin, would it
make sense to defer on further non-emergency releases of Cygwin until all
packages that are EOL have been updated?


Absolutely not.  That makes *zero* sense for an all volunteer group.

Not every single package is important to everyone.
(I am speaking personally, as maintainer of a single package on Cygwin.)

You care about Ruby?  Good.
I do not use Ruby, so that is not important *to me*.

If some specific packages are important to you, please consider finding
the maintainers of those packages and offering to help maintain those
packages.

https://cygwin.com/cygwin-pkg-maint

There are many ruby-* packages that have been orphaned.  Have at it. :)

Cheers, Glenn


Your suggestions might be given slightly more weight if you made *any*
substantive contribution besides sharing your questionable assumptions,
and opinions on work that your think *other* people (who are volunteers)
should do.

Aside: The preference on this list is to bottom-post.


> On Wed, Oct 11, 2023 at 11:15:40PM -0500, Eric D Hendrickson wrote:
>> Thanks for your reply.  Again, to the point that this is an all volunteer
>> effort.
>> And not taking away from any of what you said.
>> However, sorry I was not more clear.  The issue here is as follows.
>> Is Cygwin as a whole not more important than any one package?
>> Cygwin is distributing a suite of packages.  Are you really saying that if
>> there were a 0day vulnerability discovered in an EOL package still being
>> distributed by Cygwin, that this would do no damage to the reputation of
>> Cygwin?
>> How does Cygwin being an all volunteer effort have any bearing on this
>> question, other than the time and interest of the volunteers?
>> Perhaps the volunteer team should consider adopting a process of evaluating
>> the support status of every package it redistributes, even at the expense
>> of slowing down the rate of releases.  Or dropping packages when no one has
>> the time or interest in creating a package from a supported version of the
>> tool in question.
>> Again for the benefit of Cygwin as a whole - distributing EOL packages
>> could put Cygwin as a whole at risk, which I'm sure you would agree is much
>> worse than dropping a package from the suite.
>> This goes back to my other question -
>> Is there an Issues log or backlog a la GitHub where bugs / enhancement
>> requests / feature suggestions like this can be logged for future
>> consideration / evaluation, instead of one off discussions in this
>> ephemeral medium of email?

On 2023-10-12 09:18, Eric Hendrickson via Cygwin wrote:
> I don’t know who all is on this distribution but I’m go

setup 2.927 release candidate - please test

[Jon Turney via Cygwin]

A new setup release candidate is available at:

 https://cygwin.com/setup/setup-2.927.x86_64.exe (64 bit version)
 https://cygwin.com/setup/setup-2.927.x86.exe(32 bit version)

Please test, and report any problems here.

Changes compared to 2.926:

- Added Ctrl+K accelerator for keep or skip in package chooser (thanks 
to Christian Franke)


- Fix extracting large files (>2 GiB) from packages (thanks to Achim Gratz)
  Addresses: https://cygwin.com/pipermail/cygwin/2023-October/254562.html

- Enhance 'quiet' mode to allow window to be input-disabled or hidden

'-q'/'--quiet-mode' now accepts an optional parameter specifying how the 
setup wizard behaves: 'unattended' is the existing behaviour, 'noinput' 
also disables mouse and keyboard interaction with the wizard, and 
'hidden' hides the wizard.


- Translation updates.

- Add German and Polish translations (thanks to weblate contributors 
Markus, Ettore Atalan, Luis Mengel and WaldiS)


Some small adjustments have been made to the layout of the dialog 
templates to accommodate places where the translation is longer.  Please 
report it if there are any spots I've missed where the text overflows 
the space available.



Replies to this message are not the place for setup feature requests.

For instructions on obtaining and building the source code for setup, 
see https://sourceware.org/cygwin-apps/setup.html


Please send bug reports, as usual, to the public mailing list cygwin AT 
cygwin DOT com.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Ruby EOL in Cygwin 3.4.9?

[Eric Hendrickson via Cygwin]

I don’t know who all is on this distribution but I’m going to be very clear.

I asked a few very reasonable questions in regard to security and best 
practices for a mature and widely known product like Cygwin. In this context, 
it doesn’t matter much that it’s all volunteers except in terms of resourcing - 
the answers should be basically the same. Either it’s important to Cygwin or 
it’s not.

I’m even offering to contribute back to Cygwin.

I got no answers to my questions except “you’re stupid”.

I don’t care how many stupid questions this volunteer team gets, or random 
emails. This is unacceptable for the open source community. Or for any 
community.

The Cygwin team needs to internally examine its maturity and professionalism.  
Decisions clearly need to be made about how to communicate with the community. 
Anyone who treats people the way Glenn does should be ejected from the 
community.

Sent from Outlook on my Tricorder

From: gs-cygwin@gluelogic.com 
Sent: Wednesday, October 11, 2023 11:46:53 PM
To: Eric D Hendrickson 
Cc: Hendrickson, Eric D ; cygwin@cygwin.com 
Subject: Re: Ruby EOL in Cygwin 3.4.9?

On Wed, Oct 11, 2023 at 11:15:40PM -0500, Eric D Hendrickson wrote:
> Hello,
>
> Thanks for your reply.  Again, to the point that this is an all volunteer
> effort.
>
> And not taking away from any of what you said.
>
> However, sorry I was not more clear.  The issue here is as follows.
>
> Is Cygwin as a whole not more important than any one package?
>
> Cygwin is distributing a suite of packages.  Are you really saying that if
> there were a 0day vulnerability discovered in an EOL package still being
> distributed by Cygwin, that this would do no damage to the reputation of
> Cygwin?
>
> How does Cygwin being an all volunteer effort have any bearing on this
> question, other than the time and interest of the volunteers?
>
> Perhaps the volunteer team should consider adopting a process of evaluating
> the support status of every package it redistributes, even at the expense
> of slowing down the rate of releases.  Or dropping packages when no one has
> the time or interest in creating a package from a supported version of the
> tool in question.
>
> Again for the benefit of Cygwin as a whole - distributing EOL packages
> could put Cygwin as a whole at risk, which I'm sure you would agree is much
> worse than dropping a package from the suite.
>
> This goes back to my other question -
>
> Is there an Issues log or backlog a la GitHub where bugs / enhancement
> requests / feature suggestions like this can be logged for future
> consideration / evaluation, instead of one off discussions in this
> ephemeral medium of email?
>
> thank you and Cheers to you as well,
> Eric
>
> On Wed, Oct 11, 2023 at 10:59 PM  wrote:
>
> > On Wed, Oct 11, 2023 at 09:55:04PM -0500, Eric D Hendrickson via Cygwin
> > wrote:
> > > Sorry for the unclarity - I meant this for the whole list - not just you.
> > >
> > > Thank you so much for taking the time to respond.  Like you said, this
> > > really is all volunteers.
> > >
> > > For the whole list:
> > >
> > > Totally taking into account the all volunteer nature of Cygwin, would it
> > > make sense to defer on further non-emergency releases of Cygwin until all
> > > packages that are EOL have been updated?  Since this is the case with
> > ruby,
> > > I am guessing it's likely the case with other packages in Cygwin too.
> > >
> > > Is there a Issues log of some sort (ala github) for Cygwin somewhere, so
> > > that I can document this in the backlog and come back later to
> > investigate
> > > this myself if I have time this winter?
> > >
> > >
> > > On Wed, Oct 11, 2023 at 8:11 PM Eliot Moss  wrote:
> > >
> > > > On 10/11/2023 6:36 PM, Hendrickson, Eric D wrote:
> > > > > Hi Eliot,
> > > > >
> > > > > Thanks for responding.  That makes total sense.
> > > > >
> > > > > Totally taking into account the all volunteer nature of Cygwin,
> > would it
> > > > make sense to defer on further non-emergency releases of Cygwin until
> > all
> > > > packages that are EOL have been updated?  Since this is the case with
> > ruby,
> > > > I am guessing it's likely the case with other packages in Cygwin too.
> > > > >
> > > > > Is there a backlog for Cygwin somewhere, so that I can investigate
> > this
> > > > myself if I have time this winter?
> > > > >
> > > > > Thank you and all the best,
> > > > > Eric
> > > > >
> > > > > -Original Message-
> > > > > From: Eliot Moss 
> > > > > Sent: Wednesday, October 11, 2023 5:03 PM
> > > > > To: Hendrickson, Eric D ; cygwin@cygwin.com
> > > > > Cc: Eric @ Gmail 
> > > > > Subject: Re: Ruby EOL in Cygwin 3.4.9?
> > > > >
> > > > > On 10/11/2023 12:37 PM, Hendrickson, Eric D via Cygwin wrote:
> > > > >> Hello all,
> > > > >>
> > > > >> As a ~25 year user and sometime contributor to Cygwin, I support
> > Cygwin
> > > > here at my place of work.  Does anyone know why we are deploying Ruby

Re: Ruby EOL in Cygwin 3.4.9?

[Brian Inglis via Cygwin]

On 2023-10-11 16:47, Yasuhiro Kimura via Cygwin wrote:

From: "Hendrickson, Eric D via Cygwin" 
Subject: Ruby EOL in Cygwin 3.4.9?
Date: Wed, 11 Oct 2023 16:37:29 +


Hello all,

As a ~25 year user and sometime contributor to Cygwin, I support Cygwin here at 
my place of work.  Does anyone know why we are deploying Ruby 2.6 which EOL 
about 18 months ago?

https://www.ruby-lang.org/en/downloads/branches/

I'm concerned about proliferation of EOL versions of Ruby in case some security 
risk / 0Day is identified.

Please advise.
Eric Hendrickson


On my environment version of Ruby is 3.2.2.

(Cygwin64)yasu@rolling[1005]% uname -a  
~
CYGWIN_NT-10.0-22621 rolling 3.4.9-1.x86_64 2023-09-06 11:19 UTC x86_64 Cygwin
(Cygwin64)yasu@rolling[1006]% type ruby 
~
ruby is /usr/bin/ruby
(Cygwin64)yasu@rolling[1007]% ruby --version
~
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-cygwin]
(Cygwin64)yasu@rolling[1008]%

I use https://ftp.iij.ad.jp/pub/cygwin as download site and there are
surely ruby-3.2.2-2.hint, ruby-3.2.2-2.tar.xz, ruby-3.2.2-2-src.hint
and ruby-3.2.2-2-src.tar.xz under
https://ftp.iij.ad.jp/pub/cygwin/x86_64/release/ruby/.

So I guess download site you use is out of sync.


Current Cygwin ruby was updated to current upstream 3.2.2 six months ago; see:

https://cygwin.com/packages/summary/ruby-src.html

Checking the upstream link, preview RCs of 3.3 are available but no final 
release yet.


So it is up to you to update to the latest stable releases available on Cygwin, 
and whether any package gets updated may be influenced by what other packages 
you use which depend on earlier versions of basic language or runtime packages, 
although I am not seeing any such holdbacks.


If you are seeing such behaviour, you can check /var/log/setup.log.full to see 
the decisions made by the solver to upgrade packages.


You can also check your selected mirror(s) in /etc/setup/setup.rc e.g.

$ grep -xA3 'last-mirror' /etc/setup/setup.rc

and for the state of your mirror(s) see:

https://cygwin.com/mirrors-report.html

and only statuses after the first two are normally significant IMO.

One of my preferred local mirrors went stale and I (unusually) got no response 
from the local university mirror support webpage or email, so had to add another 
with a better record. Eventually someone did something and it is back to normal.


As Cygwin is a rolling release distribution, each package and language is 
updated as upstream makes them available, and whether and when the maintainer 
has time and confidence to release each update depends on many factors, which 
may include updates to upstream packages needed to build or run a package, and 
whether tests work successfully on Cygwin, to be confident the release provides 
stable functionality.


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

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple